Re: yet another thread question

[David Buchan <pdbuchan yahoo com>]

Wow!
Absolutely fantastic.

Thanks again John.

Dave



________________________________
 From: "jcupitt gmail com" <jcupitt gmail com>
To: David Buchan <pdbuchan 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 <pdbuchan 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