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.
