[E-Lang] Hash Chaining & Capabilities, Proposal #1b: SimplifyingPluribus

[Tyler Close]

Markm wrote:
> (Briefly, Jed suggests that only a bounded number of
> messages should be sent
> on a RemoteVow (an inter-vat promise) before hearing that
> the promise is
> resolved.  The bound should be high enough to get most of
> the benefit of
> pipelining, but, by being finite, causes an unbounded
> sending program to
> allocate only a finite amount of space in the recipient's
> vat, and instead
> allocate the unbounded amount of space in its own.  This
> causes the "pipes
> to back up" into the sender's vat, ultimately wedging it,
> rather than
> wedging the recipient's vat.

I thought this bound was already implicitly implemented. The sending
Vat can batch together a bunch of calls that use a RemoteVow, but will
not hear back from the receiving Vat until the receiving Vat has
resolved the promise. So long as the sending Vat doesn't start up
additional connections to the same receiving Vat, there is a
non-finite, but practically very small, bound on the number of
messages with the unresolved promise that the receiving Vat will
receive.

...

> >I think a small change to the Vine will fix this. When
> VatA generates
> >and sends the cap the VatB, it also includes the cap for
> the slot in
> >VatA that VatC will eventually resolve. When VatC receives
> the message
> >from VatB, and finds that the cap does not exist yet, it sends a
> >"whenResolved" message on the second cap (the one
> identifying the slot
> >in VatA). This is the same "whenResolved" message that promises
> >currently support.
> >
> >The "whenResolved" message is the standard way to impose order on
> >separate 'live' references, so it seems appropriate to use
> it to solve
> >this problem.
>
> But I'm not sure I understand your suggestion.  What do you
> mean by "slot"?
> How would this slot be connected to the Vine?

I am not intimately familiar with the E implementation of a "vine", so
do not assume that any of the nouns I use are class names.

A particular remote method call might have a return value that is
pass-by-copy. There is no way for the sending Vat to know if it will
be or not when the invocation is sent. The sending code might depend
on eventually getting a local reference to this pass-by-copy return
value; therefore, the sending Vat must allocate a deferred promise for
a local object, which it gives to the sending code. In the original
description, I referred to this deferred promise as a "slot". This
slot has two addresses. An identical slot will eventually exist in the
receiving Vat. When the sending code gives the reference for this slot
to other code, the other code must receive both addresses: the address
for the slot in the sending Vat and the address for the slot in the
receiving Vat. When the receiving Vat receives an invocation that uses
this slot reference, it first checks for the local version of the
slot. If it does not exist yet, it sends a "whenResolved" message on
the second address. I think of this second address as the "vine".

Tyler