Re: JNI thread synchronization

Date view Thread view Subject view Author view

From: Archie Cobbs (archie@whistle.com)
Date: Fri Feb 12 1999 - 13:02:05 EST


Alexandre Oliva writes:
> > 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?

OK..

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

Of course it's kaffe only, because Sun's JNI fails to provide
a standard way of doing this.

I've already tried filing a bug with Sun. They closed it out
immediately with the cause 'workaround available'.

Godmar is right, portability and JNI will never happen together.
So this would be kaffe's way of solving the problem.

-Archie

___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com


Date view Thread view Subject view Author view

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