From: Archie Cobbs (archie@whistle.com)
Date: Fri Feb 12 1999 - 12:40:00 EST
Before, I said the JNI didn't say anything about how native code
can protect itself from 'interrupts' -- ie, how to protect itself
when calling non-reentrant code. Actually this is not exactly
correct, because the JNI spec does contain a partial answer to this
problem, namely MonitorEnter and MonitorExit:
http://java.sun.com/products/jdk/1.1/docs/guide/jni/spec/functions.doc.html#5256
What I'd like to propose is that during initialization kaffe creates
a special object that is publically visible, e.g.
class kaffe.util.NativeLock {
public static final Object lock = new Object();
...
}
(The class containing this object is not important, just that
the object itself be public, static, and final)
Then all native code that needs to call any non-reentrant function,
such as printf(), malloc(), etc. would wrap this call within a
MonitorEnter(), MonitorExit() pair, using this fixed and well-known
object 'lock' as the global lock.
Alternately, we could add explicit lock and unlock methods
(they would have to be native):
class kaffe.util.NativeLock {
public static native void lock();
public static native void unlock();
}
The important thing is that all native code cooperates in the
same way. The fact that the JNI doesn't define what this way is
means we have to come up with our own.
First, does this sound like the right approach? An second, any
proposals for where 'lock' or equivalent should be? Is there
already a 'natural' choice for this object?
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT