[e-lang] Lamport slots with PBC

[Mark S. Miller]

Martin Scheffler wrote:
> OK, letting the lamport slots set up their own communication works great.
> I wrote this for the lamport reporter:
 >
> to __optUncall() :any {
>     def npbc extends lamportReporter {}
>     return [makeLamportSlot, 
 >             "localShadow",
 >             [lamportReporter.get(), npbc]]
> }
[reformatted a bit]

> now I can copy the slot from vat to vat and they stay synchronous.
> It all starts to make sense :)
> Martin

Martin, That's great!

I had meant to reply to your previous question once I'd gotten something along 
these lines to work. I'm happy to see that you're way ahead of me! A working 
distributed Lamport's Unum is a big deal! What does "npbc" stand for? How did 
you work around the fact that I still haven't fixed:
https://sourceforge.net/tracker/index.php?func=detail&aid=1635331&group_id=75274&atid=551529

Once you have something you think works, please submit changes somehow, such 
as an svn-generated *.patch file together with copies of the edited source 
files themselves. (Is there a better way for someone without commit authority 
to submit svn changes? I'm still new to svn.) I'll review, discuss and edit as 
appropriate, check in changes, and release. If your changes include any new 
files, please include an appropriate open source copyright notice near the top 
of the file. MIT X preferred. Thanks!

Once this level of functionality is solid, there are several enhancements I'd 
like to explore from here. All are microcosms of the same issues that will 
reappear for most any interesting Unums. It would be wonderful to deal with 
these issues first using this simplest-of-all stateful Unums.

* Sturdy LamportSlot distribution, where during partition, a downstream 
LamportSlot can indicate to its clients that it is providing 
potentially-more-stale-than-usual state values, and uses SturdyRef#getRcvr/2
http://www.erights.org/javadoc/net/captp/jcomm/SturdyRef.html#getRcvr(long,long)
to reconnect and reconcile upstream when it can.

* In a Grant-Matcher-style scenario,
http://www.erights.org/elib/equality/grant-matcher/index.html
where we have a diamond distributed introduction pattern, but where the 
introduction is spreading presences of the same LamportSlot Unum, the 
GrantMatcher will receive two separate downstream presences of the Unum, and 
will not be able to EQ or join[1] them. I don't believe this problem can be 
fixed within the current CapTP framework. I also don't believe that simply 
shifting CapTP from Java serialization to Data-E serialization will be 
adequate. But I'm not sure about either.

* It's unclear to me whether state-consistency among presences of an Unum 
already follow E-Order relationships, just given the implementation we have 
here (Thanks!), or whether other mechanism is necessary. If other mechanism is 
necessary, what?, and is it worth it? If not, what is the order-consistency of 
the current implementation? This question applies both to E-Order fork 
constraints, and, once the above bullet is dealt with, to E-Order join 
constraints.

* When state is large and differences tend to be small, should we communicate 
differences? Is there some general way to modify the framework to accommodate 
this?


[1] As in my section 19.5 and figures 19.2 and 19.3.

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

     Cheers,
     --MarkM