В Срд, 29/08/2007 в 14:33 +0100, jcupitt@xxxxxxxxx пишет:> 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.> Well, thanks for the suggestion. It could work if my application was ondevelopment stage, but it is in production now :). I found a solution - keep Glib::Dispatcher objects alive, until nextrequest to create new one. Just having function like (g_)gtk_main_clear_events() or(g_)gtk_main_ignore_events() would be more convinient than watchingsignal objects life time and blocking list of signals you would toignore. Regards,-andrew _______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list
