Hi Thomas, > For now this is not enabled by default. I propose to thouroughly test > > this and make it default when things turn out to work. > > This may make sense for portableNativeSync -- have you talked to the JikesRVM > developers about this change? I don't think making it the default is a good > idea though, for two reasons: > > 1) It eliminates the possibility of using the GTK AWT peers in the same > process > as another GTK-using toolkit. We've already hit this problem because SWT > does something similar to what you're proposing: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25375 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=139468 > > 2) Most GDK-using applications use the default non-reentrant lock, which means > that reentrant code paths through GDK won't have been as well-tested. If > all > AWT apps start using these code paths then this opens up the possibility > of > more subtle race conditions being exposed (we've had to track down many > over > the years, in our GTK peers and in components of GNOME). > > If we really want a reentrant GDK lock then I think we should propose the > change > to GDK itself. SWT would likely adopt the result (resolving those bug > reports) > and the GDK maintainers could help audit the current GDK/GTK code to > eliminate > reentrancy problems. Once that work has landed in GDK we'll be able to > simplify > our peer code.
I agree with that. I've filed a bugreport for GDK. Let's see how it works out. http://bugzilla.gnome.org/show_bug.cgi?id=425995 /Roman -- http://kennke.org/blog/
