I think APH may be correct. The last time I read the JNI specification,
I don't recall seeing restrictions on a JNI call including either
blocking indefinitely or never returning.
A JVM that cannot handle this behavior would seem to be broken. The
fact that changing the ATW implementation works around the breakage does
not change the fact that it is broken.
A better solution might be to hook all system calls that can block.
David Daney.
Ian Rogers wrote:
Currently, to the best of my knowledge, classpath's gtk peer code isn't
working with any JVM with M-to-N threading. The problem with
gdk_threads_enter is that it will block if it can't enter the threaded
code. If, for example, you are mapping the gtk threads to 1 native
thread then all the threads will quickly block waiting to enter
gdk_threads_enter. The solution to this is for the gtk peer code not to
block or to fix the portable native sync code - both require changes to
classpath and there are reasons not to use portable native syncing.
Whilst switching to the classpath 1-to-1 thread mapping is a desirable
change to the JVM it requires a substantial amout of work with no
developer currently working on it. A compromise could be to supply/apply
a patch when building classpath with this JVM, but I thought the issues
raised were of a more generic nature - they'd effect other JVMs that
implemented M-to-N threading.
Thanks,
Ian Rogers
Andrew Haley wrote:
Ian Rogers writes:
> Thanks for the replies. I have worked further on this and the
particular > issue isn't with GC barriers but with M-to-N threading.
It's possible that I'm completely missing the point here, but cannot
we simply conclude from this that M-to-N threading in this JVM is
broken?
Andrew.
