Re: Sending to Alternate Runners Mark S. Miller (markm@caplet.com)
Tue, 03 Nov 1998 23:15:46 -0800

At 05:23 PM 11/3/98 , Bill Frantz wrote:
>On our tree it's ec.elib.util.ExternalRef.

[-] We'll have to do something about that ;)

>It looks like an invocation
>with it takes two trips thru the run queue. If I do:
> ExternalRef foo = new ExternalRef(myRunner, object);
> E.send(foo, "message", parameters);
>
>This send results in org.erights.e.prim.E discovering that ExternalRef is
>an instance of Sendable and passing the E.send to foo's sendAll method.
>The foo.sendAll method allocates a Promise, wraps the object, method and
>parameters into a meta parameter, and queues PendingEvent(EStaticWrapper to
>invoke E, the Promise's resolver, "sendAll", meta parameters) on the run
>queue of the target vat. When the PendingEvent is dequeued, it will in
>turn, call E.sendALL to queue the actual invocation on the default vat.
>
>It seems to me that the result is the object runs in the wrong vat after an
>extra trip thru a run queue.

[-] message is delivered in the correct vat

E.sendAll() queues on the current vat. The current vat is only the default vat if E.sendAll() is called from a non-vat thread. If it's called from a vat-thread (ie, from within a vat), then the current vat is the calling vat. Therefore, the message is delivered in the correct vat.

[+] does take an "extra" trip thru the run queue.

Your description of the delivery sequence is correct. If the object is not a Sendable, the message will be queued twice before delivery.

[-] the "extra" trip is for a possibly good purpose

The (possibly bogus) reasoning goes as follows. With this implementation, if the target is a Sendable, the message gets queued only once. For a normal E.sendAll() within a vat, if the target is a Sendable, the message gets queued not at all. Otherwise, the message gets queued once. At the cost of an extra queuing, I'm preserving the relative delivery order between Sendables and non-Sendables.

This order-preservation is not required by poE, and may be too conservative. If it should be relaxed, it is trivial to simplify the ExternalRef to avoid the extra queuing -- at the price of changing the relative delivery orders. Would you like to give it a shot? Should I? Would a simplified ExternalRef meet your needs?

	Cheers,
	--MarkM