Re: apr_palloc(NULL...)

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

Hrm. We can't create a subpool for each and every file. Each subpool costs a
minimum of 8k of memory. Using a subpool for just the NULL-pool files will
add complexity and only solve NULL-pools for the file case; I'd hate to see
that complexity ripple through all of the types to deal with a feature that
we aren't sure about anyways.

I'd say that we toss the NULL pool feature.

Your fix for the permanent_pool is dead-on, however. I didn't realize that
problem had existed(!).

Regarding the multiple types of allocs... weren't we going to do that by
configuring a pool a bit differently? (e.g. have an explicit "malloc-style
pool" rather than using p==NULL to signify that)

Cheers,
-g

On Mon, Nov 27, 2000 at 06:52:30PM -0800, rbb@covalent.net wrote:
> 
> 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, ...);
>     ....
> 
> apr_close(fd)
>     ap_destroy_pool(fd..)
> 
> This will require a flag to determine if we created the pool or not, but
> that is a minimal addition.
> 
> Ryan
> 
> 
> 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
> -------------------------------------------------------------------------------
> 
> 

-- 
Greg Stein, http://www.lyra.org/