Re: Clarification of GTK/GDK locking pre GTK 4.0

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 14 September 2012 15:43, Paul Davis <paul linuxaudiosystems com> wrote:
>
>
> On Fri, Sep 14, 2012 at 6:38 AM, Emmanuele Bassi <ebassi gmail com> wrote:
>>
>>
>> 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.
>
>
> this is wierd, because i could swear that its been said many times that
> g_idle_add() is the right API to use for such things. what am i missing?

as I was just discussing this on #gtk+:

since GTK+ still supports deprecated API for marking critical sections
using gdk_threads_enter() and gdk_threads_leave(), you need to ensure
that the callback scheduled in the default GMainContext also happens
to be called under the GDK lock. this is required for libraries and
for applications that do not know if any of their dependencies can
acquire the GDK lock directly from separate threads.

if you're only using GTK+ for an application, and you're not using
threads directly, then you can skip the gdk_threads_add_* API, and use
the GMainLoop API for idle and timeout sources.

ciao,
 Emmanuele.

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