On Mon, Jun 30, 2003 at 11:23:41AM +0159, Henning Brauer wrote:
> On Mon, Jun 30, 2003 at 01:11:56PM +1000, Darren Reed wrote:
> > Why doesn't pftag_unref() do the deletion when the ref count becomes
> > 0 anyway ?  Looking at pftag_purge(), there should be no need for it.
> 
> it's been some time that I wrote that, but it was intentional. If 
> memory serves me right there is quite some likeliness that we'll need
> the same tag again shortly after the refcount reached zero. So we leave it
> there until the whole operation (ruleset reload, for example) is done, and 
> purge the ones that are still zero afterwards. That should prevent 
> fragmentation in the ID range.
> hmm, given that the old ruleset isn't deleted until the new is in 
> place that shouldn't be an issue. Had to dig deeper into it to get 
> what I was after when doing it this way again.

d'oh, of course it is intended to keep fragmentation low in the cases 
where the user flushes the old ruleset before loading a new one.

while this is not recommended, it can easily result in a fragmented ID 
space, and in teh end that can make the tag allocation much more 
expensive. As it is so easy to prevent this I decided for that way.

-- 
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)