We produce a programming environment for lisp that us GTK for gUI on non-MacOS/non-Windows platforms. It a muti-threading system, which rely on the threading capabilities of GDK (using the GDK lock, shceduling using gdk_threads_add_idle and friends). We understand that this will switched off from GTK 4.0 (based on these notes: https://live.gnome.org/Hackfests/GtkBrno2012/Notes) (side comment: that is a large step backwards). We will have to change our code for that. The issue is what happen until then, i.e. in GTK 2 and GTK 3, and whether application should be able to rely on the locks in GTK 2 and GTK 3. We are interested only in the X11 port. For example, from a bug report of a client, we found a multi-threading bug in the theme engine oxygen (using g_idle_add with functions that call GTK functions, so call them without a GDK lock). We repoted it here: https://bugs.kde.org/show_bug.cgi?id=306671 As you can see, first the developer just fixed the code, but then he was told that the GDK threads interface is deprecate, so he reverted the fix. He made a patch, but that is not good enough, because our software is used by users of our users, in many cases we don't know about them and they don't know about us and about GTK. They need robust distributions "out of the box". I think the right answer is that branches of components for GTK2 (and maybe GTK3) should continue to be compliant with the locking policy (locking the GDK around any GTK call, using gdk_threads_add_timeout and friends). What we need is an authoriative statement from the core developers of GTK of the state of play concerning the GDK lock compliane in GTK 2 and GTK 3, and components that are intended to be integrated with GTK 2 and GTK 3. As you can see from the comments in the bug above, currently people find about it from the comments that Matthias Clasen made when checked in some preparatory changes. That is useful to have, but we needs a clearer statement, in particular make it clear what happens in GTK 2 and GTK 3 and related components. Specifically concerning gdk_threads_* functions, I think they should be kept, and in GTK 4 just tail-call or define to the underline g_* functions. Maybe that is the intention, but it is currently not clear. Yehouda Harpaz _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
