Re: glib: processing events in multiple threads

[jcupitt gmail com]

On 30 April 2013 10:30, Patrick Ohly <patrick ohly intel com> wrote:
> > In my case, I'm normally processing some data in a thread using library
> > calls, then when it finishes I want to display the data to the user.
>
> That implies going fully multithreaded, including explicit passing of
> information back and forth between threads. I was hoping to avoid that.

I agree with the other posters in the thread. Keep the glib main loop
always running in a thread somewhere, don't use nested glib main loops
(g_main_context_iteration() and friends), do all the heavy work in
other threads, and have them communicate via the glib thread with
g_idle_add().

You can do this very simple and reliably. For example:

worker()
{
  char *str;

  for(;;) {
    str = g_strdup("hello world!\n");
    g_idle_add(from_worker_cb, str);
    sleep(1);
  }
}

gboolean
from_worker(char *str)
{
  update_textview(str);
  g_free(str);
  return FALSE;
}

I maintain a fairly large (>250kloc) gtk program done in this style,
calling into heavily-threaded, asynchronous libraries, and it works
well.

John