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

[Mark Miller]

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

     Cheers,
     --MarkM