From: Archie Cobbs (archie@whistle.com)
Date: Fri Feb 12 1999 - 17:28:29 EST
Godmar Back writes:
> Also, do you have the bug number for your bug report?
It never even got to bug status. Some weenie named Anand Palaniswamy
just deleted it. Tried to email him back but it bounced.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
> From Anand.Palaniswamy@Eng.Sun.COM Thu Feb 11 21:58:22 1999
> Message-Id: <199902120557.VAA19487@taller.eng.sun.com>
> From: Anand Palaniswamy <Anand.Palaniswamy@Eng.Sun.COM>
> To: archie@whistle.com
> Subject: Re: JNI specification lacks the ability to block other threads
> Cc: Anand.Palaniswamy@Eng.Sun.COM
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Mailer: postEmail @(#) PostEmail.java 1.12 99/01/14 18:29:26
> Status: ROr
>
> You can always call MonitorEnter and MonitorExit in your native code
> to make it thread safe.
>
> ----------------- Original Bug Report-------------------
>
> id : 53905
> category : java
> subcategory : native_interface
> type : bug
> synopsis : JNI specification lacks the ability to block other threads
> description : The JNI doesn't seem to talk about threading issues anywhere.
> This is bug #1: it should at least explicitly say that any
> native method code can NOT assume that it won't be preempted
> at any time by another thread.
>
> Now, having realized that JNI developers must assume the worst
> (ie, that native code can be preempted), then they face a problem
> in that this means only fully reentrant library calls can be
> made. Examples of NON-reentrant code includes malloc(), printf(),
> etc. etc.. in fact, according to POSIX, not much at all is
> guaranteed to be reentrant.
>
> The easiest solution to this problem I can see is to give the JNI
> two new methods, one for disabling preemption and another for
> re-enabling preemption.. basically "spin locks". This could be
> done in a backward compatible way.
>
> Then native code would have a way to make libc calls safely.
>
> Of course, a workaround would be to make all of your native
> methods synchronized, but this is certainly bogus and not
> appropriate in all circumstances.
> comments : (company - Whistle Communications, Inc. , email - archie@whistle.com)
> workaround : Make every native method synchronized (blech).
> cust_name : Archie Cobbs
> cust_email : archie@whistle.com
> company : Whistle Communications, Inc.
> release : 1.2
> hardware : generic
> OSversion : generic
> status : Deleted
> delReason : Workaround Available
> priority : 4
> sev_impact : 2
> sev_function : 2
> cust_type : R
> bugtraqID : 0
> dateCreated : 1999-02-08 11:38:29.0
> dateEvaluated : 1900-01-01 00:00:00.0
>
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:07 EDT