Is this the situation you are describing?
Java Thread Tcl "Owner" Thread C Thread
(thread A) (thread B) (thread C)
|
| (Problem 2)
| Call Tcl Interp???? ****
| ^
| |
+-------------> --+ Java Methods
| ^
V |
TclBlend TclBlend (Problem 1) ****
| ^
V |
C based C based
Tcl Interp Tcl Interp
(Interp #1) (Interp #2)
| ^
| |
+-------------> --+
I see two problems. First in the C layer and the other in the Java layer.
I think both problems are implementation bugs, not overall design problems.
In the C layer of TclBlend (Problem 1), many functions acquire a global
mutex at the beginning of the function, then release the mutex at the end.
You see code such as:
jint JNICALL
Java_tcl_lang_Notifier_doOneEvent(
JNIEnv *env, /* Java environment. */
jobject notifierObj, /* Handle to Notifier object. */
jint flags) /* Miscellaneous flag values: may be any
* combination of TCL.DONT_WAIT,
* TCL.WINDOW_EVENTS, TCL.FILE_EVENTS,
* TCL.TIMER_EVENTS, TCL.IDLE_EVENTS,
* or others defined by event sources. */
{
int result;
JNIEnv *oldEnv;
JAVA_LOCK(); /* !!!!!!!!! Problem 1 !!!!!!!!!!!!!! */
result = Tcl_DoOneEvent(flags);
JAVA_UNLOCK();
return result;
}
"Thread B" is typically calling "doOneEvent()", which executes the above
function in C. Since this function acquires the global mutex in
"JAVA_LOCK()", then performs "Tcl_DoOneEvent(flags)", the thread is normally
blocking while holding the "JAVA_LOCK" mutex.
Now your "Thread C", the spawned C thread, tries to use TclBlend. But to
use TclBlend, this "Thread C" must also acquire the "JAVA_LOCK" global mutex
in the TclBlend function. As a result, "Thread C" will block because
"Thread B" is holding "JAVA_LOCK".
Let's assume we somehow solve the above problem. Then "Thread C" will be
able to use TclBlend while "Thread B" is blocking on "doOneEvent()".
"Thread C" calls into some Java method. If the Java method tries to use the
event queue of its Tcl interpreter, Interp #2, then problem 2 occurs. The
Java side of TclBlend uses a single global notifier object for all its
"Interp" objects. This means that when the Java method tries to queue an
event to the "Interp #2"'s event queue, the event may actually be queued to
"Interp #1"'s event queue.
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]
-----Original Message-----
From: Scott Redman [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 15, 2000 1:34 PM
To: [EMAIL PROTECTED]
Subject: [Tcl Java] Thread question in TclBlend
I was reading Jiang Wu's paper on using Java and Tcl. I have
a question for everyone:
I want to create a single Tcl interp and access it from only
one Java thread, as per Jiang's Wrapper Layer (sending events
to the one "owner" thread). That Tcl interp will spawn
threads in Tcl and have those interps do all of the work.
As long as I'm using thread-enabled Tcl 8.3.1, this should
all work fine.
Here is the problem. I want to access Java objects through
TclBlend from each of the Tcl threads. It sounds like this
will not work, but can someone explain to me the technical
reason why? I believe this is because TclBlend doesn't
allow Tcl interps in more than one thread (from Jiang's
paper), or is this only when Tcl has not been built with
threads?
I might be able to have someone (or myself) do some of the
advance work in making this happen for tcljava 1.3. I'd
like to make sure that the discussions happen earlier
rather than later.
-- Scott
________________________________________________________________
Scott Redman mailto:[EMAIL PROTECTED]
Software Engineering Manager
Scriptics Corporation http://www.scriptics.com
----------------------------------------------------------------
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
----------------------------------------------------------------
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
