Crossing thread boundary with idle function

[Philip Boulain <prb ecs soton ac uk>]

Hullo,

  Short version:
When GTK+ is in its main run loop, blocking on an event, is there a way
to awaken/unblock it from some external thread such that it will pay
attention to newly-added idle functions?

  Long version with context:
I have a lovely multithreaded application in C++/GTKmm that I'm working
on part of (oh, lucky me), but the general problem is GTK+, not the
binding, so please just bear with the C++ names. :)

GTK+/the UI gets a thread in this system all to itself. For various
reasons, pthreads is what's being used, and GTK+ never gets to, or needs
to, know that other threads exist, as _all_ GTK+ operations occur within
this thread.

It is, however, necessary to poke this thread occasionally from another,
controlling thread. To do this, I have a notify() method, which performs
a g_idle_add() [or, in GTKmm parlance, connects to Glib::signal_idle()]
with a notifyInternal() function. notifyInternal() does the work it
needs to in the UI thread, then returns false in order to be removed
again. According to the docs, calling g_idle_add() from outside of the
Glib thread is safe, so this seems like a nice, clean way to cross the
thread boundary.

The problem with this is that adding an idle function doesn't actually
wake a blocked GTK+ main loop---the idle function won't run until some
other event, such as mouse movement, does that. It /will/ run if the
run(window) call is replaced with a while loop which does non-blocking
iteration() calls, but this is clearly horrendously inefficient.

Hence, I need to somehow need to prod the "events pending" condition
that the GTK+ loop is waiting on. My thoughts are along the lines of
giving it a synthetic event of some nature to process---hopefully at a
Glib level, as the documentation has gdk_threads_enter()/leave() as
necessary for multi-thread access to GDK and up, but not safe for the
Win32 back-end (and, yes, this abomination is also cross-platform). Any
ideas on how I can do this?

Thanks in advance,
Phil