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. >> > > >
