[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: r17214, JavaHL thread local storeage and reentrant calls

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-11-14 23:41:10 CET

On Mon, Nov 14, 2005 at 01:49:39PM -0800, Garrett Rooney wrote:
> > I admit I'm assuming that the JVM will block execution of the Java thread
> > while the JNI call is executing, but I think that's fair. I can't think
> > of anything else, so I can only conclude that I'm missing something,
> > or it's not a problem.
>
> See, that's what I'm asking. I don't know enough about JNI to make
> those sort of statements, so I'm asking for someone who does know it
> to step up and say "don't worry, that's not a problem".
>

I think that it's fair to assume the JVM will block the Java thread
while the JNI call is executing (or at least, act as-if it does).
I've just skimmed the JNI spec, and it doesn't suggest anything other
than the obvious synchronous execution model (and what would the JVM do
with the Java thread while the JNI call is executing, in any case?)

[Java doesn't have the equivalent of COMs asynchronous method calls,
as far as I'm aware, and even if it does, they're sure to be implemented
by using additional Java (worker) threads. The JNI spec doesn't mention
them.]

I think that as long as we don't use multiple threads within the JNI call
itself (and we don't, as far as I can see: neither our JNI implementation
nor our libraries create new threads), we should be okay. There's a note
about the ability for other threads to be able to 'post' an exception
to a thread executing within a JNI call ('asynchronous exceptions'),
but I don't think that's relevant.

Regards,
Malcolm

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 14 23:41:56 2005

This is an archived mail posted to the Subversion Dev mailing list.