commit 02ab0d4e56ef0daf72435b58eef93f5bdf60609b
author Thomas Haller <thaller@redhat.com> Sun Jul 27 13:52:24 2025 +0200
committer Thomas Haller <thaller@redhat.com> Mon Jul 28 17:57:57 2025 +0200
tree 30b9ed7e5612d5b063fc803c8cd849048ee848fe
parent 0f1ccd7907fa772c50015b293de637f7c80d449f

gobject: add g_object_weak_ref_sync() for thread-safe weak notifications

We have g_object_weak_ref(), which is documented to be not thread-safe.

Note that "not thread-safe" here is not quite complete. The object is
still alive (or semi-alive right before finalize()) inside the
notification callback. There is no problem with accessing the object,
even taking references (resurrection). What is not thread-safe, is to
know that when we call g_object_weak_unref(), that a concurrent thread
doesn't currently invoke the callback. And to agree on whether the
callback was invoked (once) or whether we unsubscribed it first.
Usually, you would find it hard to hit that race, because you need a
strong reference to the object to call g_object_weak_unref(), so how
could another thread have the weak notifications running? By
g_object_run_dispose().

There are multiple solutions. Commonly, we would combine
g_object_weak_ref() with GWeakRef, but that does nothing about
g_object_run_dispose(), because with g_object_run_dispose() the object
ref count is not ever going below one. Also, GWeakRef has the downside of
requiring a strong reference (which might emit toggle notifications).

Another solution is g_object_weak_ref_full() with a GDestroyNotify. The
destroy notify callback is guaranteed to be called at most once, either
by after the weak notificaiton or during g_object_weak_unref_full().
This works even with g_object_run_dispose(). The problem is that is can
be cumbersome to implement this correctly (the callbacks and the caller
of g_object_weak_unref_full() must handle this and add a proper
thread-safe mechanism themselves). The upside is, that the callback is
invoked without a lock, so it is not error prone to dead-lock.

Now add g_object_weak_ref_sync(). This invokes the weak notificaiton
while holding a lock. And g_object_weak_unref_sync() will wait on the
same lock. That means, we can atomically know that the notification is
called at most once, while not requiring GWeakRef (or strong references)
or additional synchonization. The downside is the very possibility of
dead-lock. The caller must be careful to not take a lock, that is also
held by another thread which also tries to call
g_object_weak_unref_sync().