[e-lang] makeStitchPair (was EProxyResolver and ...)

[Mark S. Miller]

Kevin Reid wrote:
> I'm impressed. Even after reading the code, the examples, and  
> experimenting with it, I still don't know how it does what it does. :)

Does the following animation help?
<http://erights.org/elib/concurrency/multi-channel/>


> The behavior I have determined experimentally: Upon each call to  
> stitch.apply(f, x), it records x, and eventually applies f to every x  
> given to the other stitch so far.

Yes.


> I also understand that it's using linked list techniques to allow the  
> item/func storage to be reclaimed when one half of the pair is  
> unreachable.

Yes.


> Questions:
> 
> Shouldn't the "store" method be a private facet? You don't give an  
> example of its use externally, and it looks like it could be used to  
> make the pair misbehave.

Yes. There's a tension here between defensive consistency and unnecessary 
complexity. The stitch abstraction is really only intended to be used to build 
multi-channels, so it seemed hard to justify the complexity of introducing 
rights amplification to access this private facet. OTOH, if we allow stitch to 
count on its clients being well behaved, as multi-channels are, then it could 
apply func immediately, rather than eventually, since the funcs provided by 
multi-channel cannot cause plan interference anyway. As is, the posted code is 
inconsistent -- being halfway between these two consistent stances.


> Given the patterns of usage so far, does that makeStitchPair do  
> anything that the following (which is built out of pieces I  
> understand) doesn't?

No, I believe it is equivalent. Further, since (unlike Joule) we're building 
on a system that already primitively supports promises, your code may be a 
better starting point than mine for adding Joule's choose operator.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM