glib/gobject
Thomas Haller 94c735a2aa gobject: don't freeze to queue notify event in g_object_notify_by_spec_internal()
Previously:

- if the object is currently not frozen, we called
  g_object_notify_queue_freeze() once. Afterwards dispatch the event
  directly. This is probably the common case, and requires one
  notify_lock lock.

- if the object is currently frozen, we call
  g_object_notify_queue_freeze(), g_object_notify_queue_add().
  g_object_notify_queue_thaw().
  This required taking the notify_lock three times.

- if the object is currently not frozen and in_init, then we called
  g_object_notify_queue_freeze(), g_object_notify_queue_freeze(),
  g_object_notify_queue_add(). This also required to take
  the lock three times. There is another thaw at the end of
  object initialization.

That was because we first call g_object_notify_queue_freeze() to see
whether we are frozen. And depending on that, queue the event (and thaw
again).

Instead, g_object_notify_queue_add() can do the check and queueing in
one step. There is no need to call a freeze() to (conditionally) enqueue
a notification. Now only one lock is taken in all cases.

Also, g_object_notify_queue_freeze() and g_object_notify_queue_thaw()
both call g_datalist_id_get_data() (which also take a bit lock). As the
thaw is no longer necessary, the second lock is also saved.
2023-12-21 07:26:50 +01:00
..
2023-10-16 23:34:04 +01:00
2022-10-13 20:53:56 -04:00
2023-10-16 23:35:05 +01:00
2022-10-13 20:53:56 -04:00
2022-10-13 20:53:56 -04:00
2023-10-16 23:34:24 +01:00
2023-12-19 18:41:02 +00:00
2023-12-19 18:41:02 +00:00
2022-10-13 20:53:56 -04:00
2022-10-13 20:53:56 -04:00
2023-10-23 11:26:53 +01:00
2023-10-23 11:26:53 +01:00
2022-10-13 20:53:56 -04:00
2023-10-23 11:26:53 +01:00