I think Problem 2 isn't a problem for what we're trying to
do, but I think you're right that it's easy to fix.
The JAVA_LOCK() is there to serialize calls to the Notifier.
This is not necessary with a thread enabled Tcl library
(--enable-threads), but is necessary for a non-thread
enabled Tcl.
The following statements are specific to Tcl 8.1+ built
using --enable-threads:
There are specific rules in threaded Tcl that we will need
to follow. First, the thread that creates an interp (in C,
but this should carry over to Java) owns the interp, and is
the *only* thread that should talk to the interp. That
thread has it's own notifier. The JAVA_LOCK() in the
doOneEvent should go away. Calling doOneEvent from another
thread will have no affect (the Notifier in C is stored
in thread-local storage). The Java Notifier should be
modeled after the C Notifier, in which there is one per
thread.
All of the C APIs are thread-safe, but you can only use
an interp (Tcl_Interp in C) from the thread that created
it.
There are APIs at the C level to send events to other
threads and optionally wait for the result. We should
add that at some point.
I think TclBlend creates a new TclInterp java object for
every C interp that loads TclBlend (if not already created).
If not, this is the way it should be. This allows any
Tcl interp to talk to and register callbacks with the JVM.
comments?
-- Scott
> It would be nice if the above two problems are solved for 1.3. I think
> TclBlend is 95% complete. The last 5% is to fix the bugs that prevent one
> from using multiple Tcl interpreters. I think "problem 2" is
> easy to solve.
> But I don't know about "problem 1" because I don't have a clear
> idea on why
> the global "JAVA_LOCK" mutex was used. My feeling is that the
> global mutex
> is not needed. Is it possible for someone at Scriptics to dig up the
> original design doc to figure out purpose of the "JAVA_LOCK"?
>
> -- Jiang Wu
> [EMAIL PROTECTED]
>
----------------------------------------------------------------
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
