Re: GTK peer switching JNIEnv *?

[Michael Koch]

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/