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

[Mark Miller]

Kevin Reid wrote:
> Simple description:
> 
> I have a Java thread from which I want to invoke a function written in 
> E. The Java thread did not start out as an E runner thread.
> 
> I see two methods:
> 
> 1.
> 
> Run the E code in its own default headless Vat/Runner and use some 
> variety of inter-thread communication. The closest thing I've found is 
> Vat#now/1, which does not provide for a return value.

Yes, since Runnables also don't provide a return value. (This isn't really a 
good excuse -- I could have defined now/1 to take a Thunk instead.)

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.


> I assume I need to use the 'boot-comm' system somehow, which I have not 
> studied. How would I do this?

If you use this now/1 technique, I don't think you'll need the boot-comm 
system. If you do want to use the boot-comm system, see Vat#seed, which is 
quite hard to use in a thread-safe manner, or seedVatAuthor.emaker, which is a 
thread-safe wrapper for Vat#seed.


> 2.
> 
> Set up a Vat running in the original thread. I assume this would require 
> writing a custom Runner that either stubs out eventual-sending or 
> implements it on top of the original thread (which will have its own 
> event loop).

Yes, it would require a custom Runner and RunnerMgr. It would also require 
adding your RunnerMgr to the Runner#RUNNER_KINDS table. I would *not* try to 
stub out eventual sending. If you implement a Runner, you may as well start 
with HeadlessRunner and make the changes so that its thread need not be a 
RunnerThread.


> For this method, how would I set up a Vat on a preexisting Runner?

Given that you've registered your RunnerMgr on RUNNER_KINDS, you'd use the 
associated runnerKind string as an argument to makeVat.


> (I assume this would be similar to the mechanism for AWT/SWT Runners, 
> but that appears to be hardcoded, and also assume that there is only one 
> such thread.)

Hmmm. I don't know whether this restriction is easy or hard to fix. If you try 
fixing this, please let me know how it goes. Thanks.


> The actual situation:
> 
> E-on-CL does not itself implement an E parser, and so uses the one 
> implemented by E-on-Java.
> 
> For typical CL implementations, I use pipes to an external Rune process. 
> However, I am attempting to add support for Armed Bear Common Lisp 
> <http://www.armedbear.org/abcl.html> which runs inside the JVM.
> 
> I am attempting to load ABCL and E-on-Java in the same JVM and 
> cross-call to the standard E parser. Therefore, I need to implement 
> synchronous-to-the-calling-side access to either EParser itself or a 
> stub on the E side.
> 
> So far I have an apparently successful imitation of Rune#main's 
> initialization code, but that results in a vat with no 
> inter-vat-reference-constraint-correct connection to my existing thread. 
> Attempting to just call the parser results, as it should, in a "no 
> current vat" error.

For the problem you're trying to solve, I think I'd use your first suggestion: 
Vat#now.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM