From 8fd75705f4bf7e9c84683bff2569757cccddd8c3 Mon Sep 17 00:00:00 2001 From: Ryan Lortie Date: Mon, 8 Oct 2012 11:20:07 -0400 Subject: [PATCH] fix g_signal_connect_object() documentation g_signal_connect_object() now works properly, so we can remove the note in the docs about it being broken. https://bugzilla.gnome.org/show_bug.cgi?id=118536 --- gobject/gobject.c | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/gobject/gobject.c b/gobject/gobject.c index 83d96ab..79c0401 100644 --- a/gobject/gobject.c +++ b/gobject/gobject.c @@ -3687,24 +3687,10 @@ g_value_dup_object (const GValue *value) * 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 - * that the signal handler is still connected before disconnected it: - * - * if (g_signal_handler_is_connected (instance, id)) - * g_signal_handler_disconnect (instance, id); - * + * When the object is destroyed the signal handler will be automatically + * disconnected. Note that this is not currently threadsafe (ie: + * emitting a signal while @gobject is being destroyed in another thread + * is not safe). * * Returns: the handler id. */ -- 2.7.4