[e-lang] E-on-Java: How to synchronously access a vat from an
markm at cs.jhu.edu
Sat Jun 25 15:02:06 EDT 2005
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:
> 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.
> 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
> 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:
Text by me above is hereby placed in the public domain
More information about the e-lang