Rob & Bob, Thanks for crashing my program and even writing variations!
rob page writes: > > Leaving me with a gut feeling that it might not like the RefPtr being > reinitialised... so i added in a src.clear() at the end of the DoIt > function and it now works.. but with warnings saying that assertion > src!=null failed... So seems like the RefPtr isn't cleaning itself up > properly after the destroy.... Forcing a clear() is something I should have tried before asking for help ... thanks for taking this step! I'm convinced that I'm not on crack now ;) Bob Caryl writes: > > when Glib::RefPtr::clear is called is that calling > Glib::TimeoutSource::destroy does not destroy the object pointed to by > its Glib::RefPtr, but merely *marks* it as destroyed and detaches it > from its MainContext; e.g. the Glib::TimeoutSource object referenced by > the created Glib::RefPtr still exists. This is how I understood it from the beginning. The destroy() idenditifier is a bit misleading - my believe is it's more on the order of detach_and_make_useless() ... nothing the documentation doesn't take care of though. I assume that in attach() references increase (quite reasonable, given the MainContext will be servicing the source) and that destroy() doesn't (or only partially so) cleans up the references attach() made. I stared at the glib/glibmm/main.[h,cc] source code just long enough to figure out I won't fully understand the solution without drawing a collaboration diagram of some sort. I hope to find time to do so and post what I find. Bob Caryl writes: > > I would suggest maybe deriving your own version of > Glib::TimeoutSource I have actually done so to use the system's up time rather than time of day so timers work correctly accross settimeofday() calls. Both glib and glibmm timeouts are triggered too soon if system time moves forward and too late if its moved backward. At least the glib(mm) timers fire at at most twice their callback interval. A one second timer in the ACE library would signal in 5 days and 1 second if system time was moved back 5 days. Needless to say that a 1.8 second timeout shines in comparison. The fix in the ACE scenario was to set a function pointer to return "time" (up time for my os) to the timer queue ... I checked out what a similar solution for the glib(mm) library that's simple enough to actually be incorporated would entail and (yet again) postponed research when I discovered optimizations in the source base class ... I better stop before I send a "you're way off topic" reply to myself - maybe I am on crack ... Bob Caryl writes: > > and using Glib::Source::add_poll and Glib::remove_poll Thanks for the potential workaround! Bob Caryl writes: > > instead of destroying and re-creating the Glib::TimeoutSource > each time your IOSource goes tango-uniform. fwiw ... I recreate the IOSource that's gone belly, not the TimeoutSource. I used TimeoutSource the example you two tested to keep code short. IdleSource would have served that purpose even better, as it too exhibits the problem, and I'm rambling again. I'll thank you both one last time and will try to come up with something useful to share. Patrick Schweiger _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
