httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: palloc without a pool
Date Wed, 08 Sep 1999 11:21:58 GMT

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.


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

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

View raw message