В Срд, 29/08/2007 в 14:33 +0100, [EMAIL PROTECTED] пишет: > On 8/27/07, Andrew E. Makeev <[EMAIL PROTECTED]> 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 on development stage, but it is in production now :). I found a solution - keep Glib::Dispatcher objects alive, until next request to create new one. Just having function like (g_)gtk_main_clear_events() or (g_)gtk_main_ignore_events() would be more convinient than watching signal objects life time and blocking list of signals you would to ignore. Regards, -andrew _______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
