Re: gdk threads ...

[Benjamin Otte <otte gnome org>]

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