Re: Clarification of GTK/GDK locking pre GTK 4.0

[Emmanuele Bassi <ebassi gmail com>]

On 15 September 2012 00:39, Andrew Cowie <andrew operationaldynamics com> 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/