Re: Sending slots to main thread (implemented)

[Chris Vine <chris cvine freeserve co uk>]

On Mon, 2007-09-03 at 16:39 +0200, Joaquim Duran wrote:

> I've modified the program to include your changes. They are working fine.
> 
> I've a question: does the g_idle_add dispatches the events at the same
> priority than the dispatcher or at a lower one?

A lower priority.  I think Glib::Dispatcher is at G_PRIORITY_DEFAULT
(Glib::PRIORITY_DEFAULT), whereas g_idle_add is at priority
G_PRIORITY_DEFAULT_IDLE, which is a lower priority in the main loop.
(They will all get dispatched by the main loop in the end however, and
once actually dispatched they run at the normal program priority - it
just determines ordering in the main loop event queue.)

You can pick any priority you like with g_idle_add_full() - see
http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-idle-add-full

You might want to change to G_PRIORITY_HIGH_IDLE, for example.

It is worth considering the pros and cons of using g_idle_add(), which
uses the event queue in the main loop (and your previous scheme by
creating a separate slot queue outside the main loop) on the one hand,
as against a sigc::signal based system such as Glib::Dispatcher on the
other hand, to see whether it suits your needs.  The main advantage of
using g_idle_add() is simplicity, in particular -

1. If there are a lot of different events requiring callbacks to be
   dispatched in the program from worker threads to the main thread,
   this avoids having separate Glib::Dispatcher objects for each event.

2. It is easier to pass arguments with varying values - they can be
   passed by value with sigc::bind and no special synchronisation is
   normally required (the call to g_idle_add() invokes locking of the
   main loop which will have the effect of securing memory
   visibility).  With a Glib::Dispatcher object it may be necessary to
   use an asynchronous queue to pass variable values (or to bind a
   reference to the data, thus normally requiring separate
   synchronisation).

But on the other hand:

1. Using slot queues is less efficient, as a new slot has to be created
   and copied every time the callback is invoked.

2. Because the slots are invoked directly rather than by being
   connected to a signal, if a slot is a non-static member function it
   cannot automatically be disconnected via sigc::trackable, so it is
   possible to invoke a method of a no-longer-existing object when the
   thread of execution of the main program loop gets round to
   executing it.

3. Multiple slots relevant to a single event cannot be invoked from a
   single call for the event - each slot has to be separately
   dispatched.

You pays your money and takes your choice.  I generally prefer a
Glib::Dispatcher approach but it is useful to have both available.

Chris