GNOME Bugzilla – Bug 637220
g_bus_own_name() triggers cancelled callbacks
Last modified: 2017-12-13 13:47:57 UTC
Created attachment 176399 [details] [review] Check if Client has been cancelled before invoking callbacks If one does g_bus_own_name() followed by g_bus_unown_name() then the registered callbacks will still be called. Attaching a patch fixing the issue.
Hmm, not sure this actually is a bug - the docs already state that things happen asynchronously. And since you might be using a GMainContext that will trigger callbacks in another thread, the patch will really do nothing since we might already have issued the callback before you get a chance to call g_bus_unown_name(). In fact we guarantee that one of the handlers will definitely be called. This patch would change that to "sometimes" even for the g_bus_own_name() followed by g_bus_unown_name().
> Hmm, not sure this actually is a bug - the docs already state that things > happen asynchronously. And since you might be using a GMainContext that will > trigger callbacks in another thread, the patch will really do nothing since we > might already have issued the callback before you get a chance to call > g_bus_unown_name(). So it's in effect an async operation that can not be cancelled. Or at least not cancelled in a way that you can cleanly detect when you get the callback. My case in point is that I have a GObject o that starts owning a name once created, and will drop the name once finalized/disposed, and I want to make it possible for consumers to do: o = my_object_new(); g_object_unref (o); and then rest assured that o is dead and gone past that point. I can use some weak-ref magic to make it work of course, but then things start getting more complicated than I had hoped for. Are you open to other ways of detecting if an "owner id" has been cancelled?
Is this the same as Bug #662808? (which looks pretty similar, but with more locking in the final commit)
(In reply to Simon McVittie from comment #3) > Is this the same as Bug #662808? (which looks pretty similar, but with more > locking in the final commit) It does look the same. *** This bug has been marked as a duplicate of bug 662808 ***