Re: Clarification of GTK/GDK locking pre GTK 4.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi;

On 14 September 2012 12:16, Yehouda Harpaz <yeh@xxxxxxxxxxxxx> wrote:
>
>>  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.
>
> That maybe interpreted to mean that scheduling UI changes in GTK+ from
> the main thread doesn't need to use the  gdk_threads_add_* API.

that's always been the case, given that signal and property
notification changes are emitted under the GDK lock.

> Need
> to make sure that _any_ scheduling of UI changes in GTK+ must use
> the gdk_threads_add_* API.

that's what I said.

>>  I hope I have answered your question.
>
> It answers my question, but it will be better to have it in something
> like "guidelines for GTK users" rather than in a mail message that
> people may or may not see. There should be something like the "Best
> Practices" page, but for users of GTK, that deal with these kind of
> issues. Specifically cases where people misinterpret something like in
> this case.

the API reference page on GDK and threads says:

"""
GTK+ is "thread aware" but not thread safe — it provides a global lock
controlled by gdk_threads_enter()/gdk_threads_leave() which protects
all use of GTK+. That is, only one thread can use GTK+ at any given
time.

[...]

Idles, timeouts, and input functions from GLib, such as g_idle_add(),
are executed outside of the main GTK+ lock. So, if you need to call
GTK+ inside of such a callback, you must surround the callback with a
gdk_threads_enter()/gdk_threads_leave() pair or use
gdk_threads_add_idle_full() which does this for you. However, event
dispatching from the mainloop is still executed within the main GTK+
lock, so callback functions connected to event signals like
"button-press-event", do not need thread protection.
"""
-- from: http://developer.gnome.org/gdk3/stable/gdk3-Threads.html

the documentation is not stellar, though; patches to clean up the
wording are very much welcome.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list



[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux