Files
glib/gobject
Thomas Haller dec3ba69e8 gobject: avoid potential race and use g_datalist_id_update_atomic() for closure array
There are two calls to

  g_datalist_id_set_data (&object->qdata, quark_closure_array, NULL);

that don't take a OPTIONAL_BIT_LOCK_CLOSURE_ARRAY lock. These are inside
g_object_real_dispose() and right before finalize(). The one before
finalize() is fine, becase we are already in a situation where nobody
else holds a reference on object.

However not so with g_object_real_dispose().  That is called after we
checked that there is only one strong reference left and we are inside
the call to dispose(). However, at that point (before chaining up
g_object_real_dispose()) the callee is able can pass the reference
to another thread. That other thread could create a Closure and destroy it
again. This calles object_remove_closure() (accessing CArray) which now
races against g_object_real_dispose() (destroying CArray).

Granted, this is very unlikely to happen. But let's try to avoid such
races in principle.

We can avoid this problem with less overhead by doing everything while
holding the GData lock, using g_datalist_id_update_atomic().  This is
probably even faster, as we don't need the additional
OPTIONAL_BIT_LOCK_CLOSURE_ARRAY lock.

Also free the empty closure data during object_remove_closure(). This
frees some unused memory.
2025-03-12 08:22:52 +01:00
..
2023-10-16 23:34:04 +01:00
2023-12-31 09:09:48 +00:00
2022-10-13 20:53:56 -04:00
2023-10-16 23:35:05 +01:00
2023-12-31 09:09:48 +00:00
2022-10-13 20:53:56 -04:00
2023-10-16 23:34:24 +01:00
2022-10-13 20:53:56 -04:00
2022-10-13 20:53:56 -04:00
2025-02-03 14:38:24 +00:00
2025-02-10 10:26:42 +01:00
2023-10-23 11:26:53 +01:00
2022-10-13 20:53:56 -04:00