[cairo] reference counting vs garbage collection

[Olivier Andrieu]

 Carl Worth [Tue, 04 Jan 2005]: 
 > The proposal of _unref()/_close() matches the resource
 > classification above. However, it doesn't capture the inherent
 > dependency between the two resources. Namely, after finalizing
 > internal state such as FILE* with _close() there's nothing useful
 > for the user to do other than _unref().  And it doesn't seem useful
 > to expose this inert object state to the user, (although the
 > implementation may need it internally).

The idea is that in a GC'ed language _unref is not exposed in the
API. It simply used behind the scenes by the GC.

 > So, I propose an _unref() function as above, and a _destroy() function
 > which is equivalent to the pair of _close() and _unref() as described
 > above.

The whole point was to separate these two calls, so that _close is
handled by the programmer and _unref by the GC (at a different time).
It lets the programmer deterministically finalize dependent objects
without interfering with the GC memory handling. It ensures that as
long as the object is reachable in the GC'ed language the refcount is
>0.

 Keith Packard [Tue, 04 Jan 2005]:
 > Here's what I think each function should do:
 > 
 >     _create	allocate object. Refcnt = 1.  Connect dependent objects
 >     _ref	refcnt++
 >     _unref	if (--refcnt = 0) { finalize dependent objects; free object }
 >     _destroy	finalize dependent objects; _unref

ah but why do an _unref in _destroy ? This way the binding has to keep
track of wether _destroy was called, so that it knows wether to _unref
or not when the object is collected.

I'd rather do this :

     _destroy	finalize dependent objects
     _unref	if (--refcnt = 0) { _destroy() ; free object }

The idea is that the GC alone manages the refcount. The programmer
calls _destroy when he wants to release the file and later the GC
would call unconditionally _unref when it collects the object.

-- 
   Olivier