On Thu, 16 Mar 2000, Jiang Wu wrote:
> TclBlend is very close to accomplish the task of using Tcl from a Java
> application. TclBlend provides the ability to call TCL commands from Java,
> and call Java methods from TCL. I am also trying to do a similar set up for
> my project at work. In my setup, I want to embed the native TCL core into a
> Java based application server process.
Very cool. The ability to load Tcl Blend and Tcl into a running JVM would
make a great addition to the 1.3 "development" version.
> I had to write a patch to the TclBlend code to make this possible. After
> patching the TclBlend code, I was able to write a tclsh like program using
> Java. The shell drives the native Tcl interpreter using a Java thread. The
> Java based shell is able to run and pass almost the same set of tests in the
> Tcl core test suite as the regular C based "tclsh.exe". My simple Java
> based shell lacks the ability to take in command line arguments so some of
> the tests failed. The Java based shell can also run all tests in the
> "tcljava" tests and "tclblend" tests in the TclBlend/Jacl suite.
tcl.lang.Interp methods can NEVER be called directly from multiple
threads. They can only be called from the event loop thread. This
is by design, it is not a bug and it will not be changed! You can
deliver events from multiple threads to a Tcl interp, but you
can not call interp methods directly.
> 1. tcl.lang.Interp methods for TclBlend cannot be called directly by any
> threads other than the one running its event loop. The Jacl Shell's console
> thread actually makes call to the tcl.lang.Interp.commandComplete() method.
> If using TclBlend, this call will block.
That sounds like a bug to me. Write up a patch and post it to the list.
The method signatures in Jacl should be exactly the same as the ones
in Tcl Blend. A good way to fix this problem "once and for all", is
to write a regression test that uses the command
"java::info methods tcl.lang.Interp" and checks each public signature
against a known list of sigs.
> In TclBlend, the Java String cannot be used directly for the value of the
> variable. The value "tcl.lang.Shell" needs to be wrapped into a TclObject
> first. This can be fixed in the TclBlend source code to add another
> "setVar" method that matches the one in Jacl.
This "wrapper layer" you describe is already written. It is called the
Notifier. You might be interested in reading a paper about Tcl Blend
and Jacl I wrote a couple of years ago. It describes the way one
should put events into the event queue in a thread safe way.
http://www.cs.umn.edu/~dejong/tcl/paper.html
Section 4.3 describes the way you add thread safe events to the event
queue.
It sounds like the "real" problem here is one of documentation. We need
to add some information to the docs about the event notifier and how
multiple threads should interact with a Tcl interp.
Jiang, do you have any time to break out the old writer's quil and
help out with the documentation? A section on multi-threaded
interaction with the Tcl interp and loading of Tcl from inside Java
would really help.
> Overall, the TclBlend stuff looks fairly good. However, to use it in a Java
> program, one has to know its idiosyncrasies. Due to multi-threaded nature
> of any Java application, one would need to write a wrapper layer on top of
> TclBlend to hide the fact that many class methods in TclBlend are not thread
> safe. The wrapper layer will be thread safe and delegate the work to
> TclBlend. For example, I would probably write a TclInterp class to wrap
> around the tcl.lang.Interp so that any thread can call
thanks
Mo DeJong
Red Hat Inc.
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
