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
