[e-lang] E-on-Java: How to synchronously access a vat from an
markm at cs.jhu.edu
Sun Jun 26 10:50:30 EDT 2005
Kevin Reid wrote:
> On Jun 25, 2005, at 21:58, Mark Miller wrote:
> Why is the boot-comm system not thread-safe? Surely its purpose covers
> communication between different runner threads.
> Is it only unsafe in that multiple threads may not access the same
> BootRef? If so, that's fine, because my thread is effectively a runner
> thread, just not one that E-on-Java recognizes.
When you send a message over boot-comm, you may be sending local PassByProxy
objects, which boot-comm needs to wrap it fresh boot-refs. To deal with this,
the BootRefHandler does a 'Vat.getCurrentVat()'. If called from a non-vat,
this will throw an error and abort the send.
> Yes, that's what I would do. But *having* that boot-ref, how do I block
> on a send to it?
Send to it from within another Vat#now
>>>> 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"?
> Running an E-on-CL-on-JVM-via-ABCL vat in the same thread as an
> E-on-Java vat, which together with allowing bidirectional synchronous
> calling, would make them arguably the same vat.
Ok, now I mostly understand the question. And are you classifying the
Vat#now-based solution as "using multiple vats"? If so, then I agree.
> ? currentVat.morphInto(AWT::runner)
> If we were to do something like this, we should probably introduce a
> runner-facet that's sufficient to create/merge vats on a runner, but not
> to shut down or otherwise modify the runner.
That sounds right.
Text by me above is hereby placed in the public domain
More information about the e-lang