Re: Clarification of GTK/GDK locking pre GTK 4.0

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 13 September 2012 16:55, Yehouda Harpaz <yeh lispworks com> wrote:

> 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 API deprecated in GTK 3.x will still be available for the duration
of the GTK 3.x lifetime (which will be years, if GTK 1.x and GTK 2.x
are of any indication). that's what deprecation means.

the API that has been deprecated is, anyway, related to *acquiring*
and *releasing* the lock from outside of GDK; the gdk_threads_add_*
API has not been deprecated, and it's considered the only way to
schedule operations from within the GDK lock.

> 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.

that revert comes from a misunderstanding. the correct fix for
scheduling UI changes in GTK+ from a non-main thread is to use the
gdk_threads_add_* API.

> 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).

that will not change for GTK 2.x and GTK 3.x, and that cannot change
without breaking ABI - i.e. the symbols will still be there until we
can bump the soname when we release GTK 4.0.

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.

the gdk_threads_add_* family of functions will stay as long as we have
a GDK lock, as their GMainLoop counterparts do not know anything about
the GDK lock; as such, we need wrappers around g_timeout_add* and
g_idle_add* that take the GDK lock before calling the callback. if we
ever change that, and deprecate gdk_threads_add_*, it will be because
we found a way to acquire the lock without a wrapper function.

> 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.

GTK+ 2.x won't have any further deprecation or addition: the API is frozen.

GTK+ 3.x will only get deprecations, and deprecated API will only be
removed when the soname is bumped for 4.0.

GTK+ 4.0 is not being worked on, yet, except for experimental branches.

the GDK threading API is available in GTK+ 2.x and 3.x; in 3.x, the
API to acquire and release the lock has been deprecated because it
conveys the wrong interaction model for multi-threaded usage of GDK
and GTK+, as well as not being portable; the gdk_threads_add_* family
of functions is still available, and it's the only acceptable way to
schedule UI changes from a different thread.

I hope I have answered your question.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/