ah, OK. this helps explain why i continue to use g_idle_add() for this purpose, then :)
actually, to be fair, i don't use g_idle_add() a lot, but rather my own implementation of the same concept that Glib::Dispatcher represents. On 7/9/12, Chris Vine <[email protected]> wrote: > On Sun, 8 Jul 2012 21:44:47 -0400 > Paul Davis <[email protected]> wrote: >> the simplest solution is actually to use the GDK idle handler. >> whenever you receive data that requires some sort of redraw, you queue >> up an idle callback that will call someWidget.queue_draw() and then >> returns false (so that it is not called again). i tend to do this with >> C (g_idle_add()) rather than C++ but IIRC the syntax is something >> like: >> >> Glib::SignalIdle().connect (sigc::ptr_fun >> (&somethingThatWillQueueARedraw)); >> >> or >> >> Glib::SignalIdle.connect (sigc::mem_fun (&some_object, >> &Object::someMethod)); >> >> Glib::Dispatcher is a more general purpose mechanism that is actually >> built on the idle mechanism if i recall correctly. > > Glib::SignalIdle.connect() is not thread safe and should definitely > not be used for what the OP wants. > > Glib::SignalIdle.connect_once() is hoped to be thread safe as of about > 2 months' ago provided that the slot object does not represent a > non-static method of a class deriving from sigc::trackable, but I don't > think that has hit a main release yet. ("Hoped to be" means that I > don't think anyone has stress tested it yet, but the code was committed > some 2 months' ago.) > > Glib::Dispatcher doesn't use the idle mechanism. On unix like systems > it uses a pipe. On win32 it uses event objects. > > Chris > _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
