So there's a proposed backport in the 1.3.x STATUS file for revision
17214, which fixes some problems with reentrant calls into JavaHL
functions. I'm not a Java/JNI person at all, so bear with me while I
try to summarize what the problem was and what the fix is, so we can
all be on the same page when I talk about a potential problem.
Patrick, please feel free to correct me if I'm wrong on any of this,
since you obviously know more about Java than I do, and you did write
the code in question.
JavaHL uses thread local storeage to keep track of a variety of
things, for example it stores Java level exceptions there, so it's
possible to say "an exception was thrown" in some C code, and then
later it gets reported to the JVM. This is all stored in this
JNIThreadData object, which is created when we enter a JavaHL function
and destroyed when we leave it. Now the problem comes from when we
call a JavaHL function from another JavaHL function, there's only one
JNIThreadData object per thread, so they stomp all over each other.
The solution was to make the JNIThreadData object really a linked
list, so when we start the second call into a JavaHL function we just
push another JNIThreadData onto the stack, use it for this call, then
pop it off at the end leaving the old one there for the existing call
to pick up and use.
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.
So is this something we need to care about? I really don't know
enough about Java/JNI to say one way or the other, but it seems weird
enough to be concerned about.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 14 19:02:58 2005