Re: GTK peer switching JNIEnv *?

[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.

Thanks,

Rob.

> Cheers,
> 
> Mark
> 
> 
>