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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
