<combining 2 of MarkM's responses into one>
At 11:15 PM 11/3/98 -0800, Mark S. Miller wrote:
>At 05:23 PM 11/3/98 , Bill Frantz wrote:
>[-] message is delivered in the correct vat
Yup. So much for my ability to read code.
>>Invoking an object in the vat.
>>[+] Runner.callNow()
>http://erights.org/doc/javadoc/org.erights.e.elib.prim.Runner.html#callNow
That's where I started. But see the next item.
>>>>Being invoked by an object in the vat.
>>[?] Can't you just call 'em?
That's what I still do. But combined with the callNow approach, it is a
recipe for deadly embrace. This one has the vat lock and the thing it
calls is synchronized. The other one is synchronized on the same object
and attempts to get the vat lock. Wait a long time.............. :-(
The best way to break this cycle is to use the vat the way it was intended,
and queue sends to the objects in it.
>>>>Waiting for Promises to be broken/kept.
>>[?] How badly do you need to do this from outside any vats?
We already use it for calling the ConnectionManager's connectToVatAt()
method. It acts as a bridge between the "throw lots of threads at it"
world and the E run queue world.
>>I quite like Jeff's approach (in the LDAP stuff I think) to device drivers
>-- wrap each separately blockable service in its own "vat". (scare quotes
>since its just like a vat, except that it blocks on this external service).
> In that case, you'd get notified of the resolution of a promise in another
>vat if you send an ExternalRef on a notifier in your vat as an argument of
>a whenResolved message to an ExternalRef on a promise in another vat.
It's a fine approach if you have some control of the code you are running.
I'm trying to act as a general service to a bunch of thread happy code. I
have to play thread synchronization games on one side and vat on the other.
(And no, I am not happy about this. But someone has to shovel out the
septic tank.)