Hi, Am Donnerstag, den 03.01.2008, 09:10 -0600 schrieb Matt Hoosier: > I've been observing a crash which shortly follows the deletion of a > Glib::Dispatcher object. The scenario goes something like this: > > * Dispatcher instance is allowed by mainloop thread > * Some UI widget registers a callback on the dispatcher > * Background thread does an emit() > * UI thread deletes the widget, including reclaiming the dispatcher > * When the mainloop becomes idle again, the GIOSource listening for > the receiver side of the dispatcher wakes up and tries to deliver the > signal to the now-reclaimed dispatcher Hm, this is a bit confusing to me. What do you mean by "allowing" and "reclaiming" the Dispatcher? > Specifically, I get a crash in the Dispatcher::pipe_io_handler > function during a GIOSource [presumably, the one registered by the > receiver side of the Dispatcher] callback execution. > > Does this sound plausible? If so, is there a known safe pattern to > avoid this race? If the Dispatcher is created and destroyed together with the widget which registers the callback, then you did indeed hit the scenario already described by Chris Vine. In my own code, I usually avoid this problem by explicitly joining the thread before the Dispatcher is destroyed. If you are careful enough, you can possibly get away without additional mutex synchronization. The attached tarball includes two source files of a small project of mine. The class PuzzleThread runs a puzzle solving algorithm in the background and also handles premature destruction by joining the thread. This solution may not be applicable in your case, though. Regards, --Daniel
Attachment:
puzzle.tar.gz
Description: application/compressed-tar