Date: Wed, 8 Sep 1999 07:21:58 -0400 (EDT)
From: Ryan Bloom <rbb@raleigh.ibm.com>
To: new-httpd@apache.org
Subject: Re: palloc without a pool
In-Reply-To: <37D6454B.BA46408@lyra.org>
Message-ID: <Pine.LNX.4.04.9909080719570.894-100000@chosondo.raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


I was actually expecting the programmer to think when he/she coded.  Maybe
that was asking too much.  I was going to implement ap_free, which did the
right thing, using the same rules as ap_palloc.  Namely, if there is a
pool pointer, do nothing, if there isn't, free the memory.

However, I like Dean's suggestion, and it will get implemented in time.
If anybody feels like doing it, by all means.

Ryan

> If ap_palloc() can take on arbitrary schemes and one of those includes a
> bare malloc(), then doesn't that imply that we must always call a free?
> (because we don't know of the ap_palloc used a pool or not)  In other
> words, just what Dean said: the abstraction seems to be destroyed.
> 
> I'm in favor of Dean's suggestion: don't use a free. ap_palloc() always
> registers a cleanup for the memory item (where the memory came from).
> 
> *If* you can free an item and *unregister* the cleanup, then sure... a
> free *could* make sense. However, I'd rather say "screw that complexity"
> and make people run the cleanups if they need to free stuff. Having
> pools *and* a free function would just be too annoying. People would
> always ask "do I have to free this here?"
> 
> Cheers,
> -g
> 
> --
> Greg Stein, http://www.lyra.org/
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.