Re: [squid-users] squid.conf: continuation lines?

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Sunday, May 13, 2001 8:21 PM
Subject: Re: [squid-users] squid.conf: continuation lines?

> 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.

> > Configuration data isn't a callback (you now when it becomes valid
> > and when its no longer needed), but more a reference you know how
> > many users there are and when that hits 0 you free it (and the
parser
> > tree has a reference to prevent it dropping below 0).
>
> 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.

> > In summary refcounting and cbdata are nearly identical, the
difference
> > being that refcounting allows use after the "config entry" is
> > reconfigured away, whereas cbdata doesn't (cbdataValid will fail).
>
> true.
>
> cbdata allows references, only difference is that it also allows you
to
> tell that the reference points to data that has been requested to be
> freed.

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.
And thats the point I'm making. Much config-derived data in squid -
peers,acls,acl lists, ntlm challenge data(it's derived from a helper
process that is config dependent) - is still valid and useful, and may
need to be locked and used for an indeterminate period of time after the
originator (the parse process) has finished with it.

While cbdata can be made to act similarly to a refcounter, no code can
use cbdatavalid on the refcounted objects.
An immediate example of this sort of race:
* we should not deny a request because a reconfigure occured between
scheduling a dns lookup callback, and the result being retrieved (can
currently happen).

> About the only type of allocations where cbdata is NOT suitable is
when
> you do not have a main reference, but all your references to the
> allocation are identical (for example a I/O buffer shared between
> multiple "threads")

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).

> The other type of allocations is when there will never be any other
> references to the data except for the main references (i.e. properly
> encapsulated data). cbdata can still be used, but a mempool is a
better
> choice then.

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?

Rob
Received on Sun May 13 2001 - 04:40:13 MDT