[e-lang] Should local promises respond to __whenMoreResolved on resolution?

Mark Miller erights at gmail.com
Mon Sep 10 00:44:52 EDT 2007


On 9/9/07, Kevin Reid <kpreid at mac.com> wrote:
> On Sep 9, 2007, at 21:44, Mark Miller wrote:
> > On 9/9/07, Kevin Reid <kpreid at mac.com> wrote:
> >> Additionally, it violates the expectation I had formed that for
> >> all x, x <- __whenMoreResolved(fn y { ... }), it is always the
> >> case that !(sameYet(x, y)).
>[...]
> I think you missed the ! in my text; the expectation is *not* upheld.

Oops. Indeed I did.


> As written, it's definitely wrong; it needs to be expressed in terms
> of traversal keys. Revision:
>
> For all properly behaving x,
>    def xk := makeTraversalKey(x)
>    x <- __whenMoreResolved(def _(y) {
>      shouldBeTrue(xk != makeTraversalKey(y))
>    })
>
> The point at which this seems to be violated is when Alice's proxy
> for Carol's promise gets __whenMoreResolved(proxy-for-Bob) and sends
> itself to the reactor proxy.

Yes. Though I don't see any problems created by this irregularity.


> >> My understanding had been -- and I was working on this code when I
> >> noticed this problem -- that WMR is never sent over over the wire
> >> (except for delayed redirection purposes) for a remote promise;
> >> rather, reactors are buffered locally, and invoked when the
> >> redirector for the proxy is invoked.
> >>
> >> Am I wrong about this?
> >
> > Yes. The protocol you're thinking of would lose the flush property.
>
> Not that I wish to defend it now, but I don't think so: delayed
> redirectors would take care of that.

Btw, I notice that Redirector and DelayedRedirector are both under MIT
X, so there's no problem reading those. DelayedRedirector only does
its delaying thing when handler.sameConnection(target) is false:

            //If the new target is a remote reference into the same vat that
            //my RemotePromise is into, then messages to be sent over target
            //will only arrive after messages previously sent on this
            //RemotePromise, so again there's no message ordering issue, and
            //we can resolve to target immediately.

so we'd still lose the flush property in this case.

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

    Cheers,
    --MarkM


More information about the e-lang mailing list