Skip to content

gdbus: cleanup faster during g_dbus_connection_signal_unsubscribe()

D-Bus signals can have a GDestroyNotify. The GDestroyNotify gets scheduled as an idle-source, which keeps the GMainContext alive. In order to prevent leaking the GMainContext, it must be iterated until the GDestroyNotify of the signal gets invoked. This is also documented by commit ab285899. This also means, that a user who cares to know when the leak is resolved, always needs to pass a GDestroyNotify to synchronize how long to iterate the context.

Cleanup "faster" in the sense that:

  • if there is no GDestroyNotify, then cleanup all data about the signal right away. The user is free to stop iterating the context right after g_dbus_connection_signal_unsubscribe().

  • if there is a GDestroyNotify, then it always gets scheduled right away (with priority G_PRIORITY_DEFAULT). Previously, the actual GDestroyNotify might be scheduled several iterations later. That means, if the user scheduled a idle-source with G_PRIORITY_DEFAULT right after g_dbus_connection_signal_unsubscribe(), then the user's idle action might be dispatched before the GDestoryNotify for the signal. This new guarantee allows the user to schedule their own idle-source to synchronize the completion of the unregistration.

This new behavior is not explcitly documented. The old documentation makes looser promises, which still apply.

Also introduce (and make use) of CList. Discussed here: #2374 (closed)

Merge request reports