Am Freitag, 14. Januar 2005 15:59 schrieb Robert Lougher: > > 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.
I don't wanna bother you but when will next jamvm version get released ? currently its hard to use because we need to apply 4 patches to jamvm to be able to run GNU classpath from CVS. Michael -- Homepage: http://www.worldforge.org/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
