Re: Glib::TimeoutSource and Glib::IOSource

[Chris Vine <chris cvine freeserve co uk>]

On Friday 13 January 2006 19:50, pks timing com wrote:
> 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 ;)

Glib::IOSource::attach() (via g_source_attach()) will increment the reference 
count maintained by the underlying GSource object.  The canonical way of 
doing this with (unwrapped) glib is as follows:

1.  Create the GSource object with g_source_new()  (ref count of 1)
2.  Attach it to the relevant GMainContext with g_source_attach() and store 
its return value (the source id) if necessary (ref count of 2)
3.  Remove the newly added reference count by calling g_source_unref() on the 
source object  (ref count of 1)
4.  When you want to destroy the source, call g_source_remove() on the source 
id (which just looks up the GSource object and calls g_source_destroy() on 
it), or call g_source_destroy() directly, or have the callback return FALSE 
(which causes g_source_destroy() to be called).

What g_source_destroy() does, via g_source_destroy_internal(), is to 
disconnect the callbacks, remove the polling object and then make one last 
unreference of the GSource object to release memory.  (It therefore will not 
release the memory associated with the GSource object if the step at 3 above 
has not been followed.) 

It looks from your report as if something in the glibmm wrapper has got the 
order of referencing/unreferencing slightly wrong.  Calling 
Glib::RefPtr<T>::clear() on the RefPtr holding the Glib::IOSource object 
shouldn't make any difference.  It unreferences the existing object (via 
Glib::Source::unreference() which calls g_source_unref()) in the same way 
that Glib::RefPtr<T>::operator=(const Glib::RefPtr<T>&) does (courtesy of a 
swap function - the unreferencing occurs when the temporary object in the 
clear()/operator=() function goes out of scope).

I suggest you post a bug on bugzilla.  In the meantime, if all else fails you 
could always use the unwrapped glib functions.

Chris