[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Etienne M. Gagnon
Subject: Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries
Date: Tue, 03 Dec 2002 17:25:25 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021128 Debian/1.2-1

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 

Etienne M. Gagnon          

reply via email to

[Prev in Thread] Current Thread [Next in Thread]