On 8/27/07, Andrew E. Makeev <andrew@xxxxxxxx> wrote: > When GUI-objects are destroyed, Glib::Dispatcher notifiers are destroyed > as well, but it happens before MAIN-LOOP actually reads all events those > were stored by notifiers. So, application crashes, when trying to access > data from Glib::DispatchNotifier structure. I have a similar thing in my (plain C) application. A set of background threads calculate image tiles for display. If an image display window is destroyed, I need to not respond to any more tile repaints from the background. My solution was simply to keep a list of valid tile generators and for my GUI thread to check each incoming tile's source. If it sees an event coming from a dead tile generator, it discards it. This is potentially crashable if an address is reused: a tile generator with a pending tile might be destroyed and a new one then made which happened to be at the same point in memory as the old one. This hasn't been a problem for me, since tile generators are only made much later, after the queue will have cleared. I guess if this is a problem you'd need the data generators to track their pending requests and cancel them all on destroy. This should be easy if you use g_idle_add() rather than Glib::Dispatcher. (I hope I've understood your problem) John _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
