[e-lang] E-on-Java: How to synchronously access a vat from an
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
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