This is similar to g_signal_connect_data(), but uses a closure which
ensures that the gobject stays alive during the call to c_handler
by temporarily adding a reference count to gobject.
Note that there is a bug in GObject that makes this function
much less useful than it might seem otherwise. Once gobject is
disposed, the callback will no longer be called, but, the signal
handler is not currently disconnected. If the
instance is itself being freed at the same time than this doesn't
matter, since the signal will automatically be removed, but
if instance persists, then the signal handler will leak. You
should not remove the signal yourself because in a future versions of
GObject, the handler will automatically
be disconnected.
It's possible to work around this problem in a way that will
continue to work with future versions of GObject by checking
This is similar to g_signal_connect_data(), but uses a closure which ensures that the gobject stays alive during the call to c_handler by temporarily adding a reference count to gobject. Note that there is a bug in GObject that makes this function much less useful than it might seem otherwise. Once gobject is disposed, the callback will no longer be called, but, the signal handler is not currently disconnected. If the instance is itself being freed at the same time than this doesn't matter, since the signal will automatically be removed, but if instance persists, then the signal handler will leak. You should not remove the signal yourself because in a future versions of GObject, the handler will automatically be disconnected. It's possible to work around this problem in a way that will continue to work with future versions of GObject by checking