Re: GTK peer switching JNIEnv *?

[Robert Lougher]

> Robert Lougher wrote:
> > So to be compliant I've got to use a separate JNIEnv for each thread,
> > but there's no point putting anything in it, because it'll break with
> > the gtk code :)
>
> No, I don't think the VM has to use different JNIEnv * pointers
> for different threads. But it may. The point is that the onus is on
> the native code to use the one provided by the VM consistently
> with that same thread, no matter what the VM does. The VM is the
> "master" and the native code is the "slave" in other words.
>
> For example, the VM could have a single JNIEnv * pointer, and then
> use pthread_getspecific() at each crossing into/out of native code
> to determine which thread it's actually dealing with.
>

And that is exactly what JamVM does, which is why it doesn't care what
the JNIEnv* is.  But people have pointed out that it is expected to be
unique and unchanging for every thread.

After making myself look well and truly stupid I should say that I
_have_ read the JNI specification.  The original one, not the book :

http://java.sun.com/j2se/1.3/docs/guide/jni/spec/jniTOC.doc.html

And that says nothing about using the JNIEnv* as a thread ID.

It says threads _may_ see a different JNIEnv* if they're called by
different threads.  Without anything explicit about being able to use
them as thread IDs, I took the "shortcut" of not bothering.  This code
was written a _long_ time ago when JamVM was just my little toy VM and
it's been lurking ever since.

Rob.

- Hide quoted text -

> -Archie
>
>