I have no problem with requiring that Tcl be compiled with --enable-threads in order to work with Tcl Blend. Keep in mind that this will be yet another nail in the coffin of a "pre built" binary version of Tcl Blend. Frankly, I think the 1.3 release should include no pre built binaries for any paltforms. If folks want to build on windows they will need to install Cygwin and or Mingwin. Mo Dejong Red Hat Inc. On Tue, 16 May 2000, Scott Redman wrote: > 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 > > ---------------------------------------------------------------- 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
