GIO Async. user data life time

[Matthew Bucknall <matthew bucknall googlemail com>]

Hi,

I am curious to know if there is a general consensus regarding how the
life time of user data passed to asynchronous operations in GIO (such
as g_output_stream_write_async) should be handled?

If I pass some GObject as user data into a async. function, then it is
surely correct that the object's reference count is incremented as the
asynchronous operation should own a reference to guarantee the user
data's existence when the callback is invoked? If that is the case, it
seems the only place I can then decrement the object's reference count
is inside the callback. This okay most of the time, but what happens
if the callback is never called (i.e. because the main loop has been
stopped)? The object that was passed as user data will never end up
being destroyed properly.

The cleanest solution I've come up to solve this problem so far is to
put a sort of freeze/thaw wrapper around g_main_loop_quit to defer the
main loop from stopping until all outstanding async. operations have
invoked their callback (often through cancellation) and therefore
unreferenced/freed any user data. This approach is far from convenient
and feels like quite a kludge.

Any better suggestions would be much appreciated. I'm hoping the
answer won't be that it doesn't matter if user data doesn't get
cleaned up because if the main loop stops the program is usually
terminating anyway - I know this is the attitude taken in some parts
of glib. In my particular case, cleanup does matter.

Matt.