The JNI provides mappings to monitor entry and exit. From google I found
this document:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniref.html#thrd
I quote:
You may find that in cases where you want access to a local system
resource like a MFC window handle or message queue, it is better to use
one Java |Thread| and access the local threaded native event queue or
messaging system from within the native code.
So, it would seem to me that this is recommending using a single Java
thread to access a local system resource which would avoid M-to-N
threading issues as M would be 1. In classpath we are currently using
multiple Java threads to access gtk. Whilst the quote is short of saying
what to do with threading and JNI, I think it is a strong hint to
programmers that this is a fairly murky area, probably because of the
mixing of threading models.
The code doesn't necessarily have to be blocked in a system call. It
could be spinning on a mutex and then calling pthread yield. A system
call is a valid GC point in the JVM, and I'm less worried about them
than I was previously. Unfortunately blocked system calls do cause some
pressure within the system and aren't desirable. Each blocked thread
consumes a thread and there's a fixed number (possibly 1) to be consumed
- which needs to be addressed :-)
So the situation is that I have 2 threads on 1 pthread. The first thread
has the gdk threads mutex. The 2nd thread wants the mutex but can't get
it so calls pthread (not j.l.Thread) yield which yields back to this
thread and we make no progress. Hijacking the yield and pointing it at
j.l.Thread.yield is possible (this is done by the portable native sync
code) but in the case the JVM has been created inside another
application, for example as a plugin, hijacking the thread yield isn't
possible. From my investigations, the portable native sync code is
broken and it doesn't seem clear to me that fixing it will produce the
best outcome - due to the plugin problem and that this approach will
never work for anything but code that uses gthreads. I think having a
modified version of the gtk peer code that addresses M-to-N threading
issue could be desirable but I wouldn't say it has to be the compile
time default. It's also possible to say that parts of classpath only
work for 1-to-1 threaded JVMs.
I hope this clears up my point-of-view. Thanks,
Ian Rogers
