On our tree it's ec.elib.util.ExternalRef. 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.
At 09:22 PM 11/2/98 -0800, Mark S. Miller wrote:
>You should generally avoid holding in one vat a direct pointer to an object
>in another vat, exactly in order to avoid confusion about what vat to send
>to it in. ExternalRef
>http://erights.org/doc/javadoc/org.erights.e.elib.helpers.ExternalRef.html
>enables you to form a safe inter-vat pointer. From within the hosting vat,
>to export a safe inter-vat pointer to one of your objects, you do
>
> Object safePtr = new ExternalRef(obj);
>
>or in the E language
>
> define safePtr := ExternalRef new(obj)
>
>If you've already got an unsafe direct inter-vat pointer, but know what vat
>the object should receive messages in, you do
>
> Object safePtr := new ExternalRef(runner, obj);
>
>or in the E language
>
> define safePtr := ExternalRef new(runner, obj)
>
>The resulting pointer is DEFERRED, so you can send on it but not call.
>This restriction makes sense, since the object is presumably in a different
>vat than the invoker. Both send* and send*Only works. (Correspondingly,
>in the E language, "<-" will work.) The implementation inside the
>ExternalRef looks somewhat like your first method below. I believe that
>Jeff has been using ExternalRefs successfully in this way.
>
>Is this adequate for your needs?
>
> Cheers,
> --MarkM
>
>
>At 06:01 PM 11/2/98 , Bill Frantz wrote:
>>Is there anything in the current E runtime which allows an
>>E.send/E.sendOnly to a runner which is not the current default runner? I
>>had to hack something together quickly, and ended up with something (in my
>>application code) which looks like (for E.sendOnly()):
>>
>> private void sendOnly(Object receiver, String verb, Object arg1) {
>> Object[] args = { arg1 };
>> myRunner.enqueue(new PendingEvent(receiver, null, verb, args));
>> }
>>
>>
>>It might be nice to have in E, something that looks like:
>>
>> public static void sendOnly(Runner runner, Object receiver,
>> String verb, Object arg1) {
>> Object[] args = { arg1 };
>> runner.enqueue(new PendingEvent(receiver, null, verb, args));
>> }
>>
>
>