[Tcl Java] Threading in tclblend.
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. 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
[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
