On Mon, Nov 14, 2005 at 10:00:45AM -0800, Garrett Rooney wrote:
> Now the problem becomes one of the mappings between the C level APR
> calls JavaHL makes to manipulate the thread local storeage and the
> Java level threads that are actually making the calls into JavaHL. If
> a C level thread and a Java level thread map to the same "thing"
> underneath, we can reasonably expect the C level thread local storeage
> to work correctly, but if the JVM is doing something fancy, mapping
> multiple Java level threads to a single OS level thread (a N-M
> threading scheme, green threads, whatever you want to call it), then
> it seems like this house of cards is likely to come crashing down.
Sorry - am I missing something here? Perhaps someone could explain why
this could cause a problem, because I don't see it yet.
JavaHL is using TLS in its implementation to store a context, effectively,
for a given call (I assume that this is an implementation-defined part
of JavaHL, and not part of the JNI interface?). The problem seems
to be that we don't know which OS thread will be used by the JVM for
a Java-JNI (for example, it might be 1:1, N:M [thread pools], or N:1
[old-style Mac OS 9 JVM, or 'green threads', whatever they are]).
I assume that the JVM can't preempt the call while it's wholly within
the JNI execution stack (since I don't see how it could), so this means
that whatever OS thread the JVM chooses to execute the JNI call, that OS
thread will be used exclusively by that Java thread for the duration of
the call. Even if we call back into the JVM and out again into another
native method (where we might get called on a different OS thread),
we won't need to pass the context object back from the second native
call to the first, will we?
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.
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 22:30:32 2005