Emmanuele Bassi <ebassi <at> gmail.com> writes: > I guess we'll have to maintain the gdk_threads_set_lock_functions(), > and internally use gdk_threads_enter()/_leave(), even if the API is > not available in public headers. > No, we will not.
If you want to use GTK, you will have to ensure that all GTK functions are called in the same thread as gtk_init(). And that's because we have lots of widgets that fiddle with their GdkScreen and potentially to backend calls. And they start doing that in their init functions and continue doing that in their exposed API. They even do that in their dispose and finalize functions. (Take that, languages that GC in different threads - which is also essentially broken and only mostly doesn't crash because we use gtk_widget_destroy() explicitly on almost all the widgets.) Otherwise you'll have to explain to me how I'm expected to write my code so that it doesn't violate the locking conventions inside GTK. Will every public GTK API call enter/leave (I'm gonna laugh at you hysterically if you suggest that) or will I not be allowed to call any GTK functions from idle handlers or gio callbacks? GTK is essentially not threadsafe at all and it would require quite a bit of effort to get it there. The current approach is a kludge. Especially because people usually (a) don't need to care about it because they properly marshal into the main loop (so all the gio and dbus callbacks inside libs are broken once you start multithreading) and (b) don't know who's supposed to take what kind of lock where. They could know if they read the code (the docs don't tell), but who does that. Benjamin _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
