> The JNI book (8.1.1) says: "The Java virtual machine passes a native > method the same JNIEnv pointer in consecutive invocations from the same > thread, but passes different JNIEnv pointers when invoking that native > method from different threads." and (11.5.1) says: "Native code may use > the JNIEnv pointer as a thread ID that remains unique for the lifetime > of the thread." > > Although I admit never having seen code actually use the JNIEnv pointer > as a unique thread ID. I do interpret this as saying that it could do > that and that the runtime must guarantee that each (java-level) thread > should have its own unique JNIEnv associated with it. >
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 :) I'll make it my internal thread structure, adding the function table pntr to the beginning -- this is obviously what the spec expects it to be. I didn't do this before because it makes the thread structure bigger, even for threads that never call into JNI. Of course, I won't be able to assume it's the right one, and still look it up via pthreads. A future optimisation. Thanks, Rob. > Cheers, > > Mark > > > _______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
