From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Sat Feb 13 1999 - 21:48:19 EST
On Feb 12, 1999, Godmar Back <gback@cs.utah.edu> wrote:
> 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.)
Then we should probably define a native lock, to be explicitly
acquired and released by non-JNI native methods, and implicitly
acquired by JNI methods. This lock would be implicitly released if
JNI code calls Java code, since it would be back in safe-land, and
implicitly acquired back upon return.
This would allow other Java threads to keep running while a JNI method
waits for some condition to return. This has the draw-back that we
can't have more than one Thread running JNI code at once, but do we
care?
BTW, I've just checked in (by accident, as you may have noticed from
the ChangeLog entry) some updates for libtool. Reportedly, libltdl
now allows one to define functions to be used instead of malloc and
free. It seems that libtool will soon be able to generate
dlpreopening symbol lists only for symbols that match a regular
expression!
--
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
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:08 EDT