In theory, JAVA_LOCK sounds like the right thing to do in protecting the notifier of a non-thread enabled Tcl interpreter. However, the JAVA_LOCK is not released while the Tcl interpreter is idling. The result is that any attempt to access the Tcl interpreter from any thread other than the "owner" thread causes deadlock. I don't think deadlock is the right level of protection. It is a bit too stringent :) It seems that we need to implement the "Calling doOneEvent from another thread will have no affect..." in the Java side of TclBlend regardless whether the underlining Tcl is thread-enabled or not. This way, there won't be any access to the Tcl interp from any thread other than the "owner" thread. Then there is no need for JAVA_LOCK at all, even for the non-threaded Tcl. What do you think? -- Jiang Wu [EMAIL PROTECTED] -----Original Message----- From: Scott Redman [mailto:[EMAIL PROTECTED]] Sent: Monday, May 15, 2000 6:45 PM To: [EMAIL PROTECTED] Subject: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend 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 ---------------------------------------------------------------- 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
