I think we should just require Tcl to be thread-enabled (as long as Tk will work with it, which is being looked into for 8.4). -- Scott > -----Original Message----- > From: Jiang Wu [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 16, 2000 11:59 AM > To: 'Scott Redman' > Cc: [EMAIL PROTECTED] > Subject: RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend > > > 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
