[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend
Will the C based Tcl extensions work the same with the threaded version of Tcl versus the non-threaded Tcl? One reason for using TclBlend is to access these extensions such as Expect and Scotty. I don't really see why we need to require the multi-threaded Tcl. If TclBlend works with multi-threaded Tcl, then it should work with a non-threaded Tcl. There needs to be better documentation clarifying things such as "when using non-threaded Tcl, you can't create a second interpreter in a different thread." But if the threaded Tcl has no problem with the extensions, then I will be OK with requiring threaded Tcl with TclBlend. -- Jiang Wu [EMAIL PROTECTED] -Original Message- From: Mo DeJong [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 17, 2000 2:25 PM To: Scott Redman Cc: Jiang Wu; [EMAIL PROTECTED] Subject: [Tcl Java] Re: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend 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 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
[Tcl Java] Re: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend
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 '[EMA
[Tcl Java] 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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Thread question in TclBlend
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
