From: Godmar Back (gback@cs.utah.edu)
Date: Fri Feb 12 1999 - 12:50:53 EST
I think we should just not call non-reentrant code from JNI code;
if it's unavoidable, the JNI code should use jthread_spinon/spinoff:
or alternatively, lets add these functions to the jsyscall interface.
Absolute source code portability with JNI is a dream anyway.
Just look at the functions that you can't call, like read() --- even
with disabling irqs or taking locks.
Or we should try these highly OS-specific linker hacks that interpose
on how, say "read", gets resolved at run-time.
- Godmar
>
> 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?
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT