After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 708643 - gsignal: add g_signal_disconnect_sync()
gsignal: add g_signal_disconnect_sync()
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-09-23 16:49 UTC by Allison Karlitskaya (desrt)
Modified: 2018-05-24 15:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gsignal: add g_signal_disconnect_sync() (8.86 KB, patch)
2013-09-23 16:49 UTC, Allison Karlitskaya (desrt)
reviewed Details | Review

Description Allison Karlitskaya (desrt) 2013-09-23 16:49:03 UTC
Thanks to Ray for the name :)
Comment 1 Allison Karlitskaya (desrt) 2013-09-23 16:49:06 UTC
Created attachment 255585 [details] [review]
gsignal: add g_signal_disconnect_sync()

This function will wait until the handler has stopped running before it
returns.  This is an elegant way to deal with the difficulties being
experienced by g_cancellable_disconnect() (which we can now deprecate).
Comment 2 Allison Karlitskaya (desrt) 2013-09-23 16:53:37 UTC
erm.  Function name in the commit message is obviously incorrect, and I lost a lovely block comment that I had explaining the whole thing during a refactor -- I'll add that back in in a future version.
Comment 3 Alexander Larsson 2013-09-24 08:13:21 UTC
Just copying my note from bug 705395 so it doesn't get lost:

Even if g_signal_disconnect_sync() solves the race on disconnect we can't fully
deprecatte the connect/disconnect pair unless we also have a story for
g_cancellable_connect() races.

I.E. unless you disconnect a handler you're supposed to get one (and only one)
callback to your handler, even if the cancellable is already cancelled on
connect time. External could could check for canceled before connecting, but
that introduces a race condition where the signal may be emitted between
checking and connecting.
Comment 4 Allison Karlitskaya (desrt) 2013-09-24 15:01:47 UTC
This does not attempt to solve the 'connect' case, which I think we cannot truly do properly, as you note.

The only place that we could even think about attempting to solve this in a generic way is for the "notify" signal on GObject.  We could say "I want a signal if the 'cancelled' property ever becomes true."  Even then, though, it seems like it would be very difficult to ensure that this worked properly.

The plan is to use this only to deprecate the g_cancellable_disconnect() API.  We would keep g_cancellable_connect().
Comment 5 Alexander Larsson 2013-10-01 15:53:28 UTC
Review of attachment 255585 [details] [review]:

Could you also add a testcase for the case where one signal handler disconnect_sync() another handler (both before and after the currently running handler).

Otherwise this looks good to me.
Comment 6 Allison Karlitskaya (desrt) 2013-11-14 20:15:22 UTC
Bug 712334 for the "show ~/Desktop if it's non-empty" thing.
Comment 7 Ray Strode [halfline] 2013-11-14 22:13:20 UTC
( comment 6 was seemingly meant for bug 712302 )
Comment 8 GNOME Infrastructure Team 2018-05-24 15:42:07 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/759.