[E-Lang] Progress & Non-Progress Report
Tue, 15 May 2001 09:50:07 +0100
At 12:20 PM 5/14/01 -0700, Mark S. Miller wrote:
> >> If the former, then
> >>forking gives them a different sameness identity, This makes hashtables
> >>containing them arrive as different hashtables.
> >The forked reference is not "==" to the original reference. The two
> references are on different timelines and so cannot be "==". A hashtable
> containing such a reference would indeed arrive as a different hashtable.
> It's likely that there is a difference in "==" between Droplets and E
> here. What are the issues here?
>Yes, this is the key difference. In E, Resolved arguments as they are sent
>are "==" to the arguments as they arrive. Yes, this does create a conflict
>regarding timelines, as I stupidly hadn't noticed till recently.
>In the current E implementation, this conflict is dealt with, sort of, by
>always having an inter-vat reference arrive as an Unresolved reference (this
>is the Lost Resolution bug). This breaks the above 'Resolved arguments as
>they are sent are "==" to the arguments as they arrive', but leaves us
>instead with 'Resolved arguments as they are sent are *eventually* "==" to
>the arguments as they arrive'
Before getting into the how, I'd like to know more about the why. The
forked reference and the original reference will never be in the same Vat
together (if they were, we wouldn't be forking), so why must the received
argument be "==" to the sent argument?
>In the proposed protocol, the issue is dealt with by using the WormholeOp to
>reconcile the timelines before the forked reference arrives in the receiving
>vat (VAtB). The WormholeOp page explains some other possible options.
So it sounds like the intended E semantics is that receipt of a reference
results in a join operation between that reference and all other references
in the same Vat that refer to the same target object. You want the comm
system to automatically collapse all the incoming timelines into a single
timeline. Is the simplified "==" definition the only reason for this?
I've got a potential problem here in supporting this in Droplets. I have to
be able to limit the lifespan of different timelines. This means that two
references may refer to the same target object, but one of those references
may be on a timeline that will be terminated while the other remains valid.
A reference does not represent unlimited ability to send messages to the
target. A reference represents the ability to send messages within a time
window determined by the reference host. So, two references may have the
same target, but different time windows. This means automatically joining
all references to the same target is not a sensible thing to do, the
intended time windows would get mixed up.
Even if I found a nifty way to support the simpler definition of "=="
(These two references refer to the same target object), I'm not sure it
would be a good thing to do. If the two references have different time
windows, they represent different authority to the target object.
> >>I'll wait for clarifications of the above issues before proceeding further.
> >There is one problem on my TODO list for the reference implementation.
> The problem is that the fork of an unresolved promise for a pass-by-copy
> object is a resolved far reference to that pass-by-copy object. This
> forked reference never gets collapsed to a local copy of the target
> pass-by-copy object. I've been mulling different ways of solving this,
> but haven't found one that I really like, so I've been procrastinating.
> My favorite contender is to have the receiving Vat do another
> "yourself/0" on the forked reference.
>In E, a Resolved reference to a PassByCopy object is always a Near reference
>to a PassByCopy object (and therefore, to a local copy if needed).
That's why it's on the TODO list. ;)