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