Here is a note from the original author of Tcl Blend on this subject.
Mo Dejong
Red Hat Inc.
Jiang Wu said:
> Then there is TclBlend, which does a nice job of linking a native TCL
> interpreter with JVM. But TclBlend assumes that the TCL interpreter
starts
> first, then it creates a JVM to run the Java code. That is the reverse
of
> my setup, in which the JVM starts first, then loads the TCL
interpreter.
TclBlend can also be used from inside a preexisting JVM. TclBlend should
only create a new JVM if it can't find one already running. You can use
the tcl.lang.Interp class to create a new Tcl interpreter and then
evaluate scripts in it. Your sample code seemed correct without any
modifications to blend. The initialization code in Tclblend_Init is only
needed if you are loading the package from C initially. It mostly just
creates a new Interp object to wrap the already existing C interpreter.
If you are creating the initial interpreter from Java, then it doesn't
need to do this.
> 1. What is the java.NativeLock monitor protecting? Is TclBlend using
the
> monitor to protect against multiple access to the C globals, access to
the
> JVM, access to the TCL Interp instance, all?
The Tcl library uses an apartment model for threads where each interpreter
hierarchy can only be used from a single thread during its lifetime.
There is a lot of state stored in thread-local variables, so you can't use
the same interp from multiple threads.
When TclBlend was originally written Tcl didn't support threading at all,
so it has probably not been modified to use the new Tcl threading
mechanisms. It should be feasible to change TclBlend so it allows
different threads to access independent interpreters. However, there is
still the challenge of matching up the Java and Tcl thread libraries. You
should be able to eliminate the monitor as long as you ensure that no Java
thread ever attempts to access an interpreter that it didn't create.
> 2. Does having the globals and a global monitor mean that there is no
> benefit in using multiple TCL interp in Java in multiple threads? All
calls
> are serialized by the monitor.
That is true. Currently all access to the Tcl library is serialized.
> 3. When the TCL Interp is idling such as in the native code of a
> tcl.lang.Notifier.doOneEvent(), TclBlend does not release the monitor.
As a
> result, any other Java thread trying to access any of the tcl.lang.*
native
> method will block due to the global monitor. Is this intended?
Yes, this is intended because the TclBlend library has not been made
thread aware. If you remove the monitor, then you need to ensure that a
given Interp object is never used outside of the thread that created it.
This goes for all of the classes in the tcl.lang package.
The one exception to this rule is the tcl.lang.Notifier.alertNotifier()
method which can be used to wake up a Tcl interpreter that is sitting in
the event loop from a different thread.
> BTW, the good news is that if I compile TclBlend without the
synchronization
> calls, my test Java program is able to load the native TCL interpreter
and
> execute TCL scripts in it. I tried out the gridDemo in the Jacl
package and
> it worked.
This should be safe as long as you never use an interpreter outside of the
thread that created it.
--Scott
----------------------------------------------------------------
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
