Re: Squid store replacement policies

On Tue, 25 Apr 2000, Henrik Nordstrom wrote:

> This is entirely up to the policy. The effect is undefined and may well
> be an assert if the policy implementator feels it is a good thing.

As you wish. My personal preference is to put "safety" in front of
"flexibility", especially when the "safe" approach costs nothing and
does not limit policy implementors in any way. I would prefer to know
that all possible policies will not allow me to do the wrong thing
rather than discover that policy A I was using before was very forgiving
and my bugs was discovered only in a production version with policy B.

IMHO, "undefined effects of API violations" are evil and should be
avoided.

> The reason why it is a walker is because the policy might need to
> maintain some special state while the purge is taking place.

Before I stop rambling, I just want to give you a last short example of
why purge walker may be "natural" but bad idea.

An iterator makes sense when there can be two different iterators
functioning independently at the same time. I suspect that your API will
prohibit creating two purge iterators (this is something that cannot be
left for the policy to decide because the users should be able to know
if they can use more than one iterator or not). If so, you have at most
one iterator at any given time. It seems natural to me that there is no
reason to make such an object public. The policy should be able to
create it internally if policy implementor wants it.

Besides, for situations where a lot of state data has to be kept to
perform a single purge, imagine the overhead (coding/interface wise) it
would take to pass that information from policy (the owner of the
relevant data) to a walker (the keeper of the state?).

On a meta level, my argument boils down to the belief that "purging the
best victim" is not an iterative process but an atomic action (given our
environment). Note that I did not use "next victim"; while "next" is
also true, the real meaning of the operation is to find the best victim
at a given time; the presence of "order" (if any) is not important to
the API user.

Alex.
Received on Tue Apr 25 2000 - 17:21:07 MDT