Re: palloc without a pool

[Greg Stein <gs...@lyra.org>]

Ryan Bloom wrote:
> > >   Allor ap_palloc to work without a pool.  Basically, this just uses malloc.
> > >   This also sets us up to allow multiple allocation methods in the same program.
> >
> > bleh.
> >
> > if you're going to use malloc like this, then just use malloc.  otherwise
> > you're paying a conditional test on every call to palloc.  not to mention
> > that there's no free() function... so you have to use free() eventually
> > anyhow, which seems to destroy the abstraction.
> 
> Actually, I will be putting free in at some point.  I haven't gotten to it
> yet.  Currently, I can't use malloc, because I am having APR do all of the
> memory allocation.  That can change pretty easily, but that's they way it
> works right now.  So, the choice becomes calling ap_palloc for any memory
> allocation, using any technique, and letting ap_palloc figure out the
> right way to do it, or having multiple memory allocation routines.  For
> right now, ap_palloc does all allocation.  If we want that to change, it
> can change after I finish what I am currently working on.

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/

Re: palloc without a pool

[Ryan Bloom <rb...@raleigh.ibm.com>]

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.	

Re: palloc without a pool

[Dean Gaudet <dg...@arctic.org>]

On Wed, 8 Sep 1999, Greg Stein wrote:

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

that wasn't quite my suggestion.  i was suggesting two allocation
interfaces... one ap_malloc/ap_free, the other ap_palloc.

ap_malloc would register a cleanup (after all, it is a pool, it's meant to
handle resource tracking)... but ap_free could be used prior to the
cleanups. 

Dean