"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.
In particular, this means, if you are writing widgets that might be used in threaded programs, you must surround timeouts and idle functions in this matter."
straight from the documentation.. http:// developer. gnome.org/ gdk/stable/ gdk-Threads. html
"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.
In particular, this means, if you are writing widgets that might be used in threaded programs, you must surround timeouts and idle functions in this matter."