On 7 Aug 2000, Jiang Wu wrote:
> On Mon, 07 August 2000, Mo DeJong wrote:
> > It looks like we might have another problem there. If we call JavaGetEnv()
> > after Tcl Blend has been loaded into Java, the current thread
> > (it is a Java created thread) would have already been attached
> > to the JVM. Would calling env->AttachCurrentThread() do anything
> > bad in this case?
>
> This is a potential problem. I don't know whether it is safe to do a
>"env->AttachCurrentThread()" on a Java thread. For maximum compatibility, let's
>assume that it is not safe to do this.
Even if it was "safe" (a no-op), it just does not seem like a good
idea. It is just confusing.
> > In the case where Tcl Blend is loaded from Java, do we want to
> > set the JNIEnv pointer during the call to JavaSetupJava? That
> > way future calls to JavaGetEnv will not try to attach to
> > the JVM again?
> >
> > tsdPtr->initialized_currentEnv = 1;
> > tsdPtr->currentEnv;
>
> I think this is the right thing to do.
>
> > This is all getting a little wacky, perhaps we need to split
> > JavaGetEnv up into JavaGetEnv and JavaInitEnv, that might
> > make things more clear.
>
> Sounds reasonable.
Ok, I am going to refactor the JavaGetEnv into an init method
and just have the current JavaGetEnv return the cached value.
If JavaGetEnv is called before the tsdPtr->currentEnv has
been set, it will assert. I will post a patch tonight.
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
