apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: apr_palloc(NULL...)
Date Tue, 28 Nov 2000 02:52:30 GMT

Just spoke to Will Rowe, and we have a potentially cleaner
solution.  Basically, we fix the make_sub_pool function so that if we call
it twice with a NULL pool, we just assign the second root pool to be a
child of the permanent_pool.  This keeps us from blowing away the
permanent pool, which is goodness.

This also allows us to create a new root pool whenever we call
apr_p(c)alloc with a NULL pool.  So, basically, we would do this if we
called apr_open with a NULL pool:

apr_open(&fd,..... NULL);
    fd->cntxt = apr_make_pool(NULL, ...);


This will require a flag to determine if we created the pool or not, but
that is a minimal addition.


On Mon, 27 Nov 2000 rbb@covalent.net wrote:

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

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

View raw message