Hi, Am Montag, den 07.01.2008, 08:43 -0600 schrieb Matt Hoosier:
> 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. Well, you would have to join *before* destroying the Dispatcher. Judging from your description, I guess this is not possible in your case? You said it's an a library -- maybe you could just fix the library directly? (I think it counts as a library bug; definitely so if there is no workaround). > 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. When I came up with the Glib::Dispatcher implementation I simply didn't think of this scenario; i.e. the internal DispatchNotifier object was never designed to live on beyond the life cycle of the last Dispatcher instance. Hm, I thought this was mentioned in the documentation but it appears it isn't stated directly, although it could probably be inferred. The life cycle of a Dispatcher is entirely the business of the receiving thread. The documentation already states that bar additional locking, the Dispatcher has to be instantiated before creating the sender thread. I'm going to add the missing information about the destruction of the Dispatcher. --Daniel _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
