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

[Mark Miller]

On 9/9/07, Kevin Reid <kpreid at mac.com> wrote:
> That I don't know all this. I've never before heard of any hint of a
> WMR handler making a decision based on the nature of the reactor. I
> see that doing so will solve the problem, but it seems (from my
> current perspective) a bit epicyclic -- piling on patches until it
> works. That's probably just because this is new to me.

I'm also torn between regarding the current protocol as elegant or
kludgy. It does succeed at an solving a large number of hard problems
with very little mechanism, which makes me lean more towards the
elegant. It's certainly better than all its predecessors, none of
which could shorten unresolved promise chains.


> 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)).

Just to be precise, even within a single vat, this is only the case
under cooperative conditions, i.e., when x does not override WMR.

Between vats, under cooperative conditions (all the vats obey the
protocol), I believe this expectation is still upheld, because by then
x will have become y. Can you propose a counter-example?


> Also, you write:
>
> > So, rather than forwarding the WMR message to Carol,
>
> 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.

If we're in the three vat shortening case previously described, the
proxy responds directly to the reactor. In all other cases, the WMR
message is sent along without buffering. But this does remind me of
another way in which a redirector is more that just
(resolver.resolve). It's also a DeadManSwitch, i.e., it overrides
__reactToLostClient in order to smash the resolver. Since the
redirector is exported when the WMR message is sent, that's all the
buffering we need.

OTOH, for __whenBroken messages, the reactor is buffered locally and
the message is not sent.

> Related question for unrelated reasons: when __whenMoreResolved is
> sent to a far ref proxy, is it sent over the wire always, never, or
> only if not fresh?

The statement above applies to both RemotePromises and FarRefs: in the
tree-vat shortening case, the reactor is notified. Otherwise, the WMR
message is always sent.

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

    Cheers,
    --MarkM