Hi David, I agree the quote is from a book and that book isn't a specification. As core library writers people can do what they want with the JNI specification and just claim the JVM is broken if it has green threads. The book which is targetting application writers who must writer code to tackle green or native threaded JVMs doesn't have this luxury, and as such is advising using a single thread as a caution in this situation. I don't think this distracts from my points. Classpath can either: 1) only work with native threaded JVMs 2) rely upon the portable native sync code to allow gtk peers to work (albeit this system needs fixing) in situations where the JVM isn't a plugin 3) be written to the same JNI standard as would be required for an application targetting both green and native threaded code I think a "--enable-green-thread-support" configure option and following choice 3 would be more appropriate than choices 1 or 2, I am however not keen to develop my own branch of classpath :-). I think you back option 1, so is it inappropriate for classpath to currently have the portable native sync code in it? The other issue of java threads that have called into non-returning JNI code tying up native threads in green threaded JVMs is a separate related issue and possibly one that can be handled by a system property. For example, a property could be called "gnu.classpath.jni.prefer.java.thread.yield" which is a hint that non-returning JNI code either calls into java.lang.Thread.yield intermittently or avoids using purely native functions (as shown in the changes of my first e-mail on this thread). Thanks, Ian Rogers David Daney wrote: > Ian Rogers wrote: >> 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 >> > > That is some tutorial. Not a specification on how JNI, JVMs or > threading systems work. > > >> >> 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. >> > > It is only a recommendation from a tutorial writer. The JVM and > runtime libraries can do whatever they want within the constraints of > the specifications. > . > . > . >> >> I hope this clears up my point-of-view. Thanks, >>
