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
