apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject apr_palloc(NULL...)
Date Mon, 27 Nov 2000 22:11:13 GMT

One of the early hacks that was added to APR was the ability to call
apr_p(c)alloc with a NULL pool.  This would make apr_p(c)alloc use malloc
internally to allocate the memory.  I would like to remove this feature,
but it has some far-reaching implications if I do, so I am checking here
first.

The problem is that the support for NULL pools has always been a bit
half-assed, and it is very difficult to get it right.  We really need a
more generalized set of memory routines that would allow people to
allocate from a pool, the heap, or shared memory.

I started to go through the APR code today to cleanup the NULL pool stuff,
and it is non-trivial.  Think about it this way, we use pools for a lot
more than just allocating memory, we also use pools for cleaning up after
ourselves.  As things stand right now, we have some serious memory leaks
in APR, because we allow people to allocate out of a NULL pool.

For example:

apr_open is called with a NULL pool, and the APR_BUFFERED flag, we will
allocate 4k on a unix machine for the buffer, that is never freed.

Even if we go through and manually free all of the allocated memory if the
pool is NULL, we still have the problem that we can't register cleanups,
so we are forcing people to manually destroy whatever variables they
create.

Can we get a quick (like within 24 hrs) decision on which direction we
want to go with this.  I plan to make the change quickly, either cleaning
up the memory leaks by manually freeing them, or removing the NULL pool
hack.

Ryan


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------





Mime
View raw message