Re: JNI thread synchronization

Date view Thread view Subject view Author view

From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Fri Feb 12 1999 - 12:50:40 EST


On Feb 12, 1999, Archie Cobbs <archie@whistle.com> wrote:

> 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();
> ...
> }

Why not just kaffe.util.Native.class?

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

This would be a Kaffe-only solution, i.e., code written with pure JNI
in mind wouldn't do that. If we're willing to address this problem,
we should probably do it without imposing any non-standard constraints
on native code. Maybe it's impossible, but then it's not our fault.
Of course we can arrange that our own native methods behave, but if we
don't take care of JNI code from others, I don't see much point...

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT