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,
