Re: understanding GtkSourceView internals

[Paolo Borelli <pborelli katamail com>]

Il giorno mer, 30/07/2008 alle 15.19 +0200, Olivier Sessink ha scritto:
> 2008/7/30 Paolo Borelli <pborelli katamail com>:
> [..]
> >> But the idle_worker functions call gdk_threads_(enter|leave) so it
> >> seems there is some multi-threading as well. What exactly is running
> >> in a separate thread?
> 
> > No, there is no work being done in threads.
> > Taking the lock in idle handlers that interact with gtk is just good
> > programming practice since the program using gtksourceview may be using
> > threads that interact with gtk concurrently with the idle handlers in
> > the main thread.
> 
> I thought that idle functions are guaranteed to be called from the
> thread that is running the main loop (which should be the thread that
> runs gdk/gtk too)??
> 

Mind you, I am far from an expert on threading issues :)

Yes, idle functions are called from the main thread but they are not
protected by the Gtk's lock:

from http://library.gnome.org/devel/gdk/unstable/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."


Ciao
	Paolo




> thanks for your answers,
>    Olivier
> _______________________________________________
> gnome-devtools mailing list
> gnome-devtools gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devtools
>