[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Threading in tclblend.
> -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 29, 2000 8:58 AM > To: Daniel Wickstrom > Cc: [EMAIL PROTECTED] > Subject: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Threading > in tclblend. > > Do you mean each Tcl thread is going to need its own JNIEnv? > Yuk, that is really going to bite. Keep in mind that Tcl This is needed to make TclBlend work well with multi-threaded Tcl. One should not assume the same Java env for all threads. In order for TclBlend to work correctly under multi-threaded condition, most of the globals used currently need to be changed into one copy per interpreter/thread. This is true for both the Java side and C side. The only globals you can have are constants and mutexes. This code about push/popping the global Java environment is not designed for multiple threads. We should not be using it if we want to make TclBlend work under multiple threads. > Would anyone really pitch a fit if we required threaded Tcl? > If it is a problem, speak up now. I don't like it, but I can live with it. It is not just Tcl. We need to take the various extensions into consideration. I use Tcl and TclBlend with extensions that are C based. These extensions that are not designed or tested under a multi-threaded environment. I have a higher confidence level in using the non-threaded Tcl with these extensions. -- 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
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] Threading in tclblend.
On Thu, 29 Jun 2000, Daniel Wickstrom wrote: > > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: > > Mo> The startup stuff is kind of tricky because we need to support > Mo> two different kinds of loading. Tcl Blend can be loaded from > Mo> Tcl, whick will then load the JVM. Tcl Blend can also be > Mo> loaded from a JVM, this means Tcl Blend will also need to load > Mo> up Tcl. > > I can see tclblend being loaded into tcl when you do something like > load tclblend into tclsh, but how do you end up with the reverse case? If you run this class from the command line (with Tcl Blend libs on the correct paths), it will load Tcl and Tcl Blend into an already running JVM. % java LoadTclBlend import tcl.lang.*; public class LoadTclBlend { public static void main(String[] args) throws Exception { Interp i = new Interp(); i.setVar("i", "1", 0); i.eval("puts \"i is $i\""); i.eval("package require java"); i.eval("set str [java::new String \"I am a Java String\"]"); i.eval("puts [$str toString]"); } } > Mo> In the case where Tcl Blend is loaded into Tcl, the > Mo> JavaGetEnv() method is called and this bit of code is > Mo> executed. > > Mo> if (currentEnv != NULL) { return currentEnv; } > > O.k. you only init these structures once. I see that, but what I > don't understand is what happens when another thread comes along and > uses the JNIEnv pointer stored in currentEnv. My understanding about > this is that for each thread the JNIEnv pointer is different. My work > on nsjava where I've integrated a jvm to work with aolserver's tcl > interpreters has shown me that this is true. Also the class, method, > etc., id's stored in the "java" structure need to be different for > each thread. I think I'm missing something here about the over-all > architecture of tclblend. Is there only one tcl interpreter thread in > tclblend or are there multiple tcl interpreters? Do you mean each Tcl thread is going to need its own JNIEnv? Yuk, that is really going to bite. Keep in mind that Tcl Blend was originally written for Tcl 8.0, which had only one Tcl thread, so that could be a problem. We probably do not run into problems with a threaded verison of Tcl because we use the "big global lock" in JAVA_LOCK (this needs to be removed, it will kill multithreaded performance). > Just my opinion, but I would require that tcl be compiled with > threads. It seems that it would make things alot simpler. Of course > I'm biased, as aolserver will only ever use threaded interpreters :). > What is your current user base like? Do you think alot of people > have a need for a non-threaded interpreter? I know the threaded > version is probably slower, but I wonder if it is that significant. Would anyone really pitch a fit if we required threaded Tcl? If it is a problem, speak up now. > As I get into this more, I might have something to offer. In nsjava, > I attach the jvm to the connection thread, so I have one tcl > interpreter per thread, I cache the JNIEnv pointer in a cache that is > indexed with the thread id. The only locking that I do is when I'm > accessing the cache to either put a new env pointer into it or to pull > an env pointer out. I've run this setup under high-load situations > using apache bench, and I'm not seeing any lock contention. Basically > I only support one new tcl command called ns_java which is roughly > equivalent to your java::call tcl commmand. I understand enough about > how aolserver works now, so I could probably extend this to give > nsjava functionality equivalent to tclblend, but I would rather see if > I can merge tclblend into nsjava. Providing aolserver with the > ability to script java components from tcl would be a very powerful > feature that I think many people would find useful for web based > development. I think it would be much better than accessing java > through jsp. Your expert help in this area would be great. Post a note to the list if you need any help with merging Tcl Blend stuff into your existing code. Mo DeJong Red Hat Inc 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] Threading in tclblend.
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: Mo> The startup stuff is kind of tricky because we need to support Mo> two different kinds of loading. Tcl Blend can be loaded from Mo> Tcl, whick will then load the JVM. Tcl Blend can also be Mo> loaded from a JVM, this means Tcl Blend will also need to load Mo> up Tcl. I can see tclblend being loaded into tcl when you do something like load tclblend into tclsh, but how do you end up with the reverse case? Mo> In the case where Tcl Blend is loaded into Tcl, the Mo> JavaGetEnv() method is called and this bit of code is Mo> executed. Mo> if (currentEnv != NULL) { return currentEnv; } O.k. you only init these structures once. I see that, but what I don't understand is what happens when another thread comes along and uses the JNIEnv pointer stored in currentEnv. My understanding about this is that for each thread the JNIEnv pointer is different. My work on nsjava where I've integrated a jvm to work with aolserver's tcl interpreters has shown me that this is true. Also the class, method, etc., id's stored in the "java" structure need to be different for each thread. I think I'm missing something here about the over-all architecture of tclblend. Is there only one tcl interpreter thread in tclblend or are there multiple tcl interpreters? Mo> The tricky part is how Tcl is compiled. If Tcl is compiled Mo> with threads support enabled, then you could use a Tcl mutex Mo> to protect the resources. Problem is, some people might not Mo> want to use the thread enabled version of Tcl. I am kind of Mo> leaning towards requiring the thread enabled version of Tcl Mo> for Tcl Blend because I think going for a simple solution and Mo> avoiding using JNI when we can is a very good thing. Just my opinion, but I would require that tcl be compiled with threads. It seems that it would make things alot simpler. Of course I'm biased, as aolserver will only ever use threaded interpreters :). What is your current user base like? Do you think alot of people have a need for a non-threaded interpreter? I know the threaded version is probably slower, but I wonder if it is that significant. Mo> We would certainly welcome any suggestions or insights you Mo> might have on the subject. I hope that we can get all these Mo> threading issues ironed out in the next 3-4 weeks so that we Mo> can cut a 1.3.0 release of Jacl and Tcl Blend for people to Mo> bang on. As I get into this more, I might have something to offer. In nsjava, I attach the jvm to the connection thread, so I have one tcl interpreter per thread, I cache the JNIEnv pointer in a cache that is indexed with the thread id. The only locking that I do is when I'm accessing the cache to either put a new env pointer into it or to pull an env pointer out. I've run this setup under high-load situations using apache bench, and I'm not seeing any lock contention. Basically I only support one new tcl command called ns_java which is roughly equivalent to your java::call tcl commmand. I understand enough about how aolserver works now, so I could probably extend this to give nsjava functionality equivalent to tclblend, but I would rather see if I can merge tclblend into nsjava. Providing aolserver with the ability to script java components from tcl would be a very powerful feature that I think many people would find useful for web based development. I think it would be much better than accessing java through jsp. Dan 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] Threading in tclblend.
On Thu, 29 Jun 2000, Daniel Wickstrom wrote: > I've been experimenting with integrating tclblend into aolserver, and > after looking at the tclblend code, I'm a little puzzled about > something. In javaCmd.c the variable java declared as type JavaInfo > and currentEnv are declared as global variables, yet I would think > that these two variables would be overwritten each time a new thread > starts up. Am I missing something? I've noticed using of java locks > throughout the code. Maybe only one thread can be executing c-code at > any given time? Any insights would be appreciated. This is an area of ongoing discussion. Check out the online mainling list archive for the history. http://www.mail-archive.com/tcljava@scriptics.com/ The startup stuff is kind of tricky because we need to support two different kinds of loading. Tcl Blend can be loaded from Tcl, whick will then load the JVM. Tcl Blend can also be loaded from a JVM, this means Tcl Blend will also need to load up Tcl. In the case where Tcl Blend is loaded into Tcl, the JavaGetEnv() method is called and this bit of code is executed. if (currentEnv != NULL) { return currentEnv; } That should only let you init the global once (minus any race conditions, which I will cover in a second). In the case where Tcl and Tcl Blend are loaded into a JVM, Java_tcl_lang_Interp_create() is the first native method that gets called. Java_tcl_lang_Interp_create( JNIEnv *env,/* Java environment. */ jobject interpObj) /* Handle to Interp object. */ { jlong lvalue; Tcl_Interp *interp; JNIEnv *oldEnv; int loadedFromJava = (currentEnv == NULL); /* true if Tcl Blend was loaded into Java */ if (! loadedFromJava) { PUSH_JAVA_ENV(); } interp = Tcl_CreateInterp(); if (JavaSetupJava(env, interp) != TCL_OK) { jclass err = (*env)->FindClass(env, "tcl/lang/TclRuntimeError"); In this case we don't do a Java lock (because that monitor has not been init'ed yet), and we call JavaSetupJava(). Inside JavaSetupJava() we have some code like this: if (initialized) { return TCL_OK; } // Setup from inside a JVM initialized = 1; return TCL_OK; So, the globals "initialized" and "currentEnv" should only get init'ed once. That should work in almost every case, but we still have some race conditions to work out. For example, in the unlikely case that two Interp() objects were created at the exact same time, one might be half way into the init when the second one noticed an init had not been done and started another one. The unresolved question about the race conditions is how you are going to do the lock the resource. In the case where Tcl Blend is loaded into Tcl, you need to init the JVM before you can use a JVM monitor through JNI. In the case where Tcl Blend and Tcl are loaded into a JVM, you could use a Java monitor to do the lock. The tricky part is how Tcl is compiled. If Tcl is compiled with threads support enabled, then you could use a Tcl mutex to protect the resources. Problem is, some people might not want to use the thread enabled version of Tcl. I am kind of leaning towards requiring the thread enabled version of Tcl for Tcl Blend because I think going for a simple solution and avoiding using JNI when we can is a very good thing. We would certainly welcome any suggestions or insights you might have on the subject. I hope that we can get all these threading issues ironed out in the next 3-4 weeks so that we can cut a 1.3.0 release of Jacl and Tcl Blend for people to bang on. Mo DeJong Red Hat Inc 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