Re: guidelines for refcounting / cbdata

On Tuesday 28 January 2003 02.08, Robert Collins wrote:
> Do these seem right?
>
> *) Use cbdata for any asynchronous calls, where the caller may
> disappear during the calls duration. I.e. calling a acl checklist
> from a http request object. An alternative but more complex
> approach is to have 'backwards facing' refcounting, where the
> callee holds a reference to the caller. Such a design needs more
> thought than cbdata, and cbdata is advised unless it is
> insufficient for the needed behaviour.

Right. This is what cbdata is designed for.

> *) Use refcounting where
> multiple objects may use a single object, and no 'last user' can be
> guaranteed. I.e. refering to a specific acl entry from a checklist.

Right. This is not suitable for cbdata.

> *) Use both if needed following the programmer guide howto. I.e. a
> shared resource (say store entry) that may pass itself to a async
> callback object.

Dual use of an object needs to be analysed carefully.

If you have the situation that there is a single owner who may cancel
the object at "any time" on nobody should be using the object when
cancelled then cbdata is the correct mechanism. This is suitable for
callback objects but also some other kinds of references.

If you have a shared resource which cannot be cancelled and should be
freed when no one is longer using it then refcounting is the correct
approach.

If you want to mix the two then care must be taken in how/when objects
are invalidated to not trash the data while there is refcount users.

For freeing of related resources and cleanup cbdata offers two
alternatives:

a) Manual free of the related resources and invalidation of the
object. This is incompatible with shared use of the object unless
each such use is cbdata aware (in which case it must be a cbdata
reference, not a refcount reference, and the user must always verify
the object before use).

b) A free callback, called when the last reference to the object is
gone or immediately at invalidate if there is no references. This
method is compatible with refcounting as nothing happens to the
object data when it is invalidated. Care must be taken to not create
looped references in such use (a -> b -> c -> a)

Regards
Henrik
Received on Tue Jan 28 2003 - 02:05:55 MST