On 6 July 2012 14:49, David Buchan <pdbuc...@yahoo.com> wrote:
> If I understand the first solution correctly, we're creating a separate idle
> function for each message. If the worker thread gets a bit ahead of the GUI
> updates, then a few idle functions might pile up. ok. But one thing I don't
> understand is that these idle functions will be spawned by the worker thread
> (not from the main gtk context), and I thought only the main gtk iteration
> was allowed to muck around with the textview (or any other part of the GUI).
That's right, only the main thread can touch the textview.
Idle callbacks are always run by the main thread. The worker is simply
adding a function pointer and a data item to the list of jobs that the
main thread will perform next time it hits idle. glib has some locks
to make this thread-safe.
g_idle_add() looks something like this inside:
g_idle_add (function, data)
LOCK (main_thread_idle_list)
main_thread_idle_list.append (function, data)
UNLOCK (main_thread_idle_list)
and the main thread runs something like this every time it's idle:
main_thread_idle()
LOCK (main_thread_idle_list)
while (main_thread_idle_list)
function, data = main_thread_idle_list.pop_head
function(data)
UNLOCK (main_thread_idle_list)
so calling g_idle_add() from the worker queues a job for the main
thread. Calling g_idle_add() from a worker is like sending an
asynchronous message from the worker to the main thread.
John
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
