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
