Re: main loop & asynchronous queues

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 22 Sep 2009 18:59:25 -0500
Thomas Stover <thomas wsinnovations com> wrote:
> Does glib allow for things like a two threaded program with
> inter-thread communication via async queues while each thread has a
> separate main loop waiting for both external stimulus and new queue
> messages to arrive? In other words, a) can a main loop be made to run
> a callback when a queue message arrives without polling (possibly
> futex based on linux),

I do not know of a way to poll a condition variable, (which seems to be
what you are asking) other than by the stand wait call for the
condition variable, but it would be the wrong way to achieve what you
want even if you could, first because it would be completely
non-portable and secondly because in glib a thread can cause the main
loop for another thread to execute an arbitrary callback by means of an
idle source.

In the case of callbacks to execute in the default program loop/context
(the "main" main loop) a worker thread can use g_idle_add()/
g_idle_add_full().  To execute a callback in other threads' main loops
you will have to do it in long-hand, making a GSource object with
g_idle_source_new(), and attach it to the GMainContext for the thread
in question (it is relatively trivial).

http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description

You won't need an asynchronous queue as you can pass whatever
data you want to g_idle_add() or your custom event poster.  Each main
loop retains its own (thread-safe) event queue.  You can give any
priority in the loop you want to an idle handler ("idle" is something
of a misnomer, just reflecting the default priority).

> and b) can two threads each have a main loop?

Yes.  Each can have their own GMainContext and thus their own GMainLoop
objects.  Every GMainContext object is owned by a thread.

Chris