On Jan 7, 2008 1:07 AM, Daniel Elstner <[EMAIL PROTECTED]> wrote: > Hm, this is a bit confusing to me. What do you mean by "allowing" and > "reclaiming" the Dispatcher?
Oh, sorry. That was a typo. I meant "allocating" and "reclaiming". I.e., constructor and destructor. > > > 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. Well, the application already does this. It seems like joining on the background thread has no effect here, because the "damage" is that the byte is already written to the pipe before the background thread exits. Then there's the Glib::signal_io() handler sitting out there waiting to fire on the UI thread's side of things, possibly after the Dispatcher has already been destructed. I know that the DispatcherNotifier object attempts to avoid this by doing conn_io_handler_.disconnect() in its own destructor, but the crash inside pipe_io_handler() after I'm certain that the destructor for the Dispatcher has run, makes me wonder if this isn't really disconnecting the GIOChannel underneath. --Matt _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
