Re: Glib::TimeoutSource and Glib::IOSource

[pks timing com]

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