Hi Damian, Damjan Jovanovic wrote:
That only leaves Java's usage of GTK as a suspect.
I agree. GTK LAF was meant to be used from a single thread (EDT), so no measures were taken to ensure thread safety.
On http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html we read that while GDK locks are not reentrant, they can be safely replaced by locks that are reentrant, and the java-gnome library successfully does just that. Unfortunately for us gdk_threads_set_lock_functions() only exists since GDK 2.4 -> no go.
I'd not say no go; GTK 2.2 is already aged, and by the time JDK7 ships it would be extinct. So i'd drop support for it completely (we have some 2.2-specific code now, both Java and C).
OTOH i don't see how set_lock_functions() is going to help. On the filedialog thread we run the smart gtk_main() function that releases the lock when it's not needed. But on EDT we don't run it, so we ourselves must define points where to grab and release the lock. It seems reasonable to grab the lock once we're in the native code, and release it just before going back to Java. This seems to be the approach you're taking with your patch.
Thanks! -- Peter | x33066 | location: SPB04 | timezone: GMT+03
