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
