clarify section about gdk_threads_enter/ gdk_threads_leave to be reworded

Thu Jul 12 18:12:04 2007  Tim Janik  <timj@imendio.com>

        * gdk/tmpl/threads.sgml: clarify section about gdk_threads_enter/
        gdk_threads_leave to be reworded in terms of events and to mention
        availability of gdk_threads_add_idle_full().



svn path=/trunk/; revision=18457
This commit is contained in:
Tim Janik 2007-07-12 16:13:11 +00:00 committed by Tim Janik
parent c3bb9a4fa3
commit 920147ee8f
2 changed files with 14 additions and 6 deletions

View File

@ -1,3 +1,9 @@
Thu Jul 12 18:12:04 2007 Tim Janik <timj@imendio.com>
* gdk/tmpl/threads.sgml: clarify section about gdk_threads_enter/
gdk_threads_leave to be reworded in terms of events and to mention
availability of gdk_threads_add_idle_full().
2007-07-11 Matthias Clasen <mclasen@redhat.com>
* gtk/tmpl/gtkrange.sgml:

View File

@ -31,12 +31,14 @@ You must call g_thread_init() and gdk_threads_init() before executing
any other GTK+ or GDK functions in a threaded GTK+ program.
</para>
<para>
Idles, timeouts, and input functions 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.
(However, signals are still executed within the main
GTK+ lock.)
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 GtkWidget::button-press-event, do not need thread protection.
</para>
<para>
In particular, this means, if you are writing widgets that might