Andrew Haley wrote:
Maybe you know something I don't. Is there any wordage in the JNI
spec that forbids blocking calls, or suggests that this might be
problematic? Is there any wordage in the JNI spec that allows the
Jikes RVM to behave in the way that it does with repect to blocking
calls?
Andrew,
I am concerned about green threads and problems caused on JVMs using
them by classpath - the issues with blocking threads and synchronization
have been highlighted. As I understand the JNI spec. it is designed to
explain how to access Java objects, invoke Java methods from native
code. It is a specification of an API and doesn't state what is valid
native code - it would have to address a large number of APIs to do
that. The book "Advanced Programming for the Java 2 Platform" that I
quoted from does shed some light on what programmers using the JNI API
can do, and they recommend that JNI programmers accessing MFC in their
example but GTK for us, should use a single Java thread. I would argue
their reasoning for this is that it avoids green threading problems. I
don't believe we should use a single thread to handle GTK peer code, but
we need to address the problems the current GTK peer code has with green
threaded JVMs. This leads to 3 solutions:
1) declare green threaded JVMs unsuitable for use with parts of classpath
2) try to fix the portable native sync code - which has issues that I
keep repeating
3) have conditionally compiled/run code that makes the code behave
better in the situation of a green threaded JVM
My reasons for posting was to see what people believe is the correct
route from these 3 alternatives.
Thanks,
Ian
