Re: cbdataFree

cbdata types are meant to be used in two ways:

1. A "original" pointer, as returned from cbdataAlloc.

2. Reference pointers, all locked with cbdataLock.

When the "original" pointer is cbdataFree()d then all reference pointers
are marked as invalid (cbdataValid() returns false).

If you look in the cbdata branch all this is a lot clearer. There the
cbdataLock/Unlock calls has been replaced by cbdataReference/Unreference
using slightly different syntax glue to empasis the intended use and
lessen the risk for errors, and the programmers guide extended to better
explain the cbdata use.

Note: Many parts of Squid uses cbdata in bad ways and there is needs for
a quite big cleanup there.. most of the errors is in how data is freed
(members should be freed by the callback, not by the function calling
cbdataFree(). This because there might be references using these members
without verifying the reference validity...)

If you only wish to use them as "reference counted allocations" then you
can theoretically do this by only saving a reference pointer..

    foo = cbdataAlloc()
    saved_foo = foo; cbdataLock(foo);
    cbdataFree(foo);
...
    cbdataUnlock(saved_foo);

but I would not encourage such use of cbdata, even if I have done so
myself in the eventio branch (but only temporarily until some better
mechanism for reference counted allocations can be found).

cbdata is a quite nice thing, but reference counting is only a sideffect
of what is needed to implement cbdata, not the main feature of cbdata
as. If you need reference couting but not cbdata then a pure reference
couting should be used.

--
Henrik
Robert Collins wrote:
> 
> This macro:
> 
> #define cbdataFree(var) (var = (var != NULL ? cbdataInternalFree(var):
> NULL))
> 
> is a problem for me:
> I'm build a refcounted structure.
> the cbdata code has provision to allow the following sequence:
> 
> CBDATA_INIT_TYPE_FREECB(footype, freefoo)
> 
> foo=cbdataAlloc(footype);
> cbdataLock(foo);
> cbdataFree(foo);
> 
> access, lock and unlock foo until a matching
> cbdataUnlock(foo);
> occurs and then freefoo(foo) is automatically called.
> 
> However the above macro is setting foo to NULL !? (because
> cbdataInternalFree is returning NULL).
> 
> Is this by design or oversite?
> 
> Rob