Re: squid.conf: cbdata / rcdata

Robert Collins wrote:

> > Same thing as reference counted allocation, except that we know that
> the
> > allocation is stale. Since it is stale we know that addressing ->next
> is
> > not a good idea unless we have that one locked as well.
>
> If that list is implemented properly (ie using the dlink
> primitives) ->next will always be valid, cbdata or refcounted data.

Only problem is that it currently isn't.

> > For many things it is also good to know that the reference is stale,
> for
> > example a peer. Not all operations on the peer is valid if it is not
> the
> > current configuration entry for that peer.
>
> I'm not clear on what operations would be invalid.

For example to start probing the peer on connection failures and a other
operations which are indirectly caused.

> Not true. cbdata tells you _the first_ reference, or the _originator_
> (depending on who calls cbdatafree) no longer has a pointer to the data.
> It _does not_ tell you whether the data is a) invalid _or_ b) no longer
> needed by the originator/first reference.

True, but for most data it is the same thing, especially so for
configuration data.

> I'm not disagreeing: I'm pointing out that config-derived variables
> behave in that fashion in squid. (substitute request state for thread
> and config item for io buffer).

And to this I do not agree.

> So we have three allocators:
> 1) mempools. possible example: the actual buffer in a I/Obuffer. (the
> metadata - buffer size, offset into the buffer, data length is in a
> refcounted struct)

> 2) cbdata. possible example: temporary state data used in a well known,
> predicatable path. (ie with callbacks to catch call-twice issues and the
> like).

> 3) rcdata: possible example: the iobuffer header struct above, or config
> data :], or __any data that may need a "free" to occur in multiple
> independent code paths__.

> One thing I'm not clear on henrik:
> Do you think refcounted data is inappropriate for config entries?

Yes. When I have a reference to config data I'd like to know if it is
the current configuration or not. This makes it different from for
example shared I/O buffers which does not have any main reference, only
users. For the example of peers whe have discussed this is especially
important as there might be a number of background jobs refering to the
peer, and if the peer configuration they refer to is stale these should
abort (will get started again with the current configuration).

The discussion on how Squid currently handles the configuration data is
moot as for most entries it is neither pooled or cbdata alocated, and
for many of the entries where it actually is cbdata allocated it is done
wrongly/poorly.

--
Henrik