Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries

[Etienne M. Gagnon]

Artur Biesiadowski wrote:
> > So, you probably agree that adding an indirection for doing "blocking
> > calls" and providing VM-specific implementation of those calls is not
> > a good idea.
>
> Please note that this trick is more useful then just making life easier 
> for Kissme at the moment (because their JNI needs to be fixed anyway I'm 
> afraid). It can be also used by any jvm which wants to implement n-to-m 
> thread model (or even green threads).

No.  It is the responsibility of the VM to single out threads running JNI code 
into real system threads.  A VM should not require native code to do anything 
special other than call than communicate through the documented JNI specified 
interface.  Doing otherwise defeats the purpose of JNI.


> I suppose, that all this trick could be done even transparent for most 
> jvms. ...

I still don't see any reason to do so (other than going around some flaw in a 
JNI implementation).  I think the JNI specification is clear enough: as long as 
a  native library communicates with a VM through the JNI interface as documented 
(e.g. not sharing JNIEnv pointers across threads, etc.), the system should be 
well behaved.  So, it is inferred that blocking calls either:
- block the whole VM (expected [yes!] when using green threads), or
- the VM deals with it (in a n-to-m implementation -> native code is singled 
out).

Etienne
--
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/