On 15 September 2012 00:39, Andrew Cowie <andrew@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2012-09-14 at 11:38 +0100, Emmanuele Bassi wrote: >> in any case, though, the deprecations refer to gdk_threads_enter() and >> gdk_threads_leave() which, as I said above, are functions to acquire >> and release the GDK lock from third party code. > > I'm confused. Is a language binding "third party code"? Or does this > mean that the GDK lock will continue to exist and we can continue to use > gdk_thread_enter/leave() to guard our calls to GTK functions? If so, > that would be great! we cannot break ABI for the duration of the 3.x series, so the gdk_threads_enter()/leave() functions will have to exist in the GTK+ SO; given that there are applications still using them with threads, they need to keep working to avoid regressions and applications breaking - at least on X11, on Windows they would break anyway. third party code using GTK+ should, though, strive to move away from a model of taking locks and hoping for the best, and towards a model where only one thread at a time accesses the GUI, and all other threads schedule work through the main loop. it's not impossible that, after a certain amount of years have elapsed, and once we know that the biggest users of GTK+ and threads have been migrated away from the "acquire the GDK lock in a thread" pattern, then the GDK lock gets removed and the gdk_threads_enter()/leave() functions will stop doing anything; if that happens, though, there will be a further notification to application developers. alternatively, if applications are not migrated, we'll have to wait the next ABI/API bump to GTK+ 4.0 to remove the GDK lock. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
