> 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 > > _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
