Wow! Absolutely fantastic. Thanks again John.
Dave ________________________________ From: "jcup...@gmail.com" <jcup...@gmail.com> To: David Buchan <pdbuc...@yahoo.com> Cc: gtk-app-devel-list list <gtk-app-devel-list@gnome.org> Sent: Friday, July 6, 2012 10:16 AM Subject: Re: yet another thread question 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
