[e-lang] E-on-Java: How to synchronously access a vat from an external thread?

Mark Miller markm at cs.jhu.edu
Sat Jun 25 21:58:43 EDT 2005

Kevin Reid wrote:
> On Jun 25, 2005, at 15:02, Mark Miller wrote:
>> ...In any case, it's easy to work around this limitation by providing 
>> a Runnable that stores the return value in an internal field whose 
>> value you can then access.
> Yes, but this would break the inter-vat reference constraints. (What's a 
> better term for that?)

It would indeed be good to have a term for that. Suggestions?

> The particular data I have in mind right now is 
> all Strings, but if it wasn't, this would be unsuitable as a general 
> solution.

If you want to use E from outside a vat, we currently have no general 
solution. You're on your own regarding thread safety issues.

For a more general solution, perhaps we could try to create a thread-safe 
version of the boot-comm system, so that boot-refs could be safely invoked 
from external non-vat threads. I don't really know if this approach could 
work, or how hard it would be.

 > I'll do this for now, anyway.


> Ah. I'd forgotten that Vat#seed did the Right Thing.
> If I did this, how would I block the external thread until the result of 
> a send to the seed-result ref resolves?

Perhaps you could combine it with the Vat#now mechanism -- have your Runnable 
call seed, and store the resulting boot-ref for your external thread to get.

>> Yes, it would require a custom Runner and RunnerMgr. It would also 
>> require adding your RunnerMgr to the Runner#RUNNER_KINDS table.
> I thought so. I want to do this such that it works with an unmodified E 
> distribution. (Of course this could be changed, but it wouldn't work 
> *now*. And using multiple vats instead of an intra-vat bridge is 
> arguably the Right Thing.)

What are you referring to when you say "intra-vat bridge"?

>> Given that you've registered your RunnerMgr on RUNNER_KINDS, you'd use 
>> the associated runnerKind string as an argument to makeVat.
> But in this case, there would not necessarily be only one thread of this 
> kind - so putting them in RUNNER_KINDS (if that were to become a mutable 
> table) would not be very capability-structured, as it would introduce a 
> global namespace. This is really what I meant when I mentioned assuming 
> only one thread.

You're right, the whole "runnerKind" string mechanism that we've got now is 
rather ugly and unprincipled. What would be a better architecture for this?

Btw, another thing I don't like in the present architecture is that there's no 
public object that corresponds to a Runner. The Runner class is encapsulated, 
but the Runner concept is exposed. The Vat interface exports methods to deal 
with both Vats and Runners, which in retrospect was bad API design. Reifying 
Runners may also help fix the issues you raise above.

Text by me above is hereby placed in the public domain


More information about the e-lang mailing list