refcount: Clarify when the ref count ends up undefined

Calling g_atomic_ref_count_dec() or g_ref_count_dec() and the reference
count reaches zero results in different side effects depending on
whether the reference count is atomic or not.

The intended side effect when this happens is undefined, i.e. one should
not rely on the reference count actually reaching zero, or staying 1, or
becoming something else, and one should treat the grefcount /
gatomicrefcount to be unusable until reinitialized.

This wasn't documented, so add a paragraph about this.
This commit is contained in:
Jonas Ådahl 2021-04-09 11:13:36 +02:00
parent 346e4867ea
commit 21cc809158

View File

@ -142,6 +142,10 @@ void
* *
* Decreases the reference count. * Decreases the reference count.
* *
* If %TRUE is returned, the reference count reached 0. After this point, @rc
* is an undefined state and must be reinitialized with
* g_ref_count_init() to be used again.
*
* Returns: %TRUE if the reference count reached 0, and %FALSE otherwise * Returns: %TRUE if the reference count reached 0, and %FALSE otherwise
* *
* Since: 2.58 * Since: 2.58
@ -249,6 +253,10 @@ void
* *
* Atomically decreases the reference count. * Atomically decreases the reference count.
* *
* If %TRUE is returned, the reference count reached 0. After this point, @arc
* is an undefined state and must be reinitialized with
* g_atomic_ref_count_init() to be used again.
*
* Returns: %TRUE if the reference count reached 0, and %FALSE otherwise * Returns: %TRUE if the reference count reached 0, and %FALSE otherwise
* *
* Since: 2.58 * Since: 2.58