RE: squid.conf: cbdata / rcdata

> -----Original Message-----
> From: Henrik Nordstrom [mailto:hno@hem.passagen.se]
> Sent: Monday, May 14, 2001 1:58 AM
> To: Robert Collins
> Cc: squid-dev@squid-cache.org
> Subject: Re: squid.conf: cbdata / rcdata
>
>
> Robert Collins wrote:
>
> > 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.

I'm happy to fix that in generic modules. I've already rewritten the
parser, and the acl code is now clearer.
 
> > 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.
 

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

Knowing whether an item foo is part of the active config makes sense.
However I'm not convinced that tying "memory valid" to "active
configuration" is appropriate. What if you want 2 in-memory configs for
a short period of time?

Note: the example with peers is opposite to the behaviour with acls: the
acl test has no mechanism for restarting, and should not be restarted
with a new config, but completed with the old config.

It's easy enough to add a "active" flag to parser nodes, to allow your
desired peer behaviour, but it's harder to make cbdata behave like
refcounted data (ie for acls) than the reverse.
 
> 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.

This is becoming less of an issue as I start to wrap up the parser work.
(Which is why I need to be clear on the allocator issue). Much of squid
now simply uses the parser to handle the creation of storage locations.
The actual parsed data is not always stored as cbdata (ie Int values :])
but to make the whole system consistent that will probably need to
happen.

For now:
I'll use cbdata, and think some more on this.

 
> --
> Henrik
>
Received on Sun May 13 2001 - 17:33:33 MDT