Re: JNI thread synchronization

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Fri Feb 12 1999 - 16:31:01 EST


 
 BTW, one possibility is to never switch out of a signal handler when
using user-level threads. Instead, have the signal handler simply set a
flag "something happened, a reschedule might be needed". The JIT would
insert polls at every backbranch to check that flag.

For native threads it's not that much a problem because they come with
thread-safe libraries. Although not with async-signal-safe libraries,
either, but that could be implemented similarly.

        - Godmar

>
>
> Sorry for sending piecewise mail like this, but I just thought about it
> some more and I feel that unconditionally blocking irqs (or what would amount
> to taking a spinlock on an SMP) for the duration of a JNI call is
> probably also not what we want, (especially if that JNI code may block
> or call back into jthreads.)
>
> I guess it has to do with the question Alexandre raised: should we attempt
> to support user JNI code to the best of our abilities or not.
>
> It's such a mess.
>
> - Godmar
>
> >
> > I wrote:
> > >
> > > Let's put softcalls in the JNI wrappers for the JNI part. That slows
> > > it down some. Probably not much, though.
> >
> > Actually, I just looked at it and it does a softcall already.
> > So we can just add the on/off to startJNIcall and finishJNIcall.
> > The interpreter can be handled in support.c, I think.
> >
> > - Godmar
> >
> >
>
>


Date view Thread view Subject view Author view

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