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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] > > 406 29th St. > > San Francisco, CA 94131 > > ------------------------------------------------------------------------------- > > > > > > > > > > > > > _______________________________________________________________________________ > Ryan Bloom [EMAIL PROTECTED] > 406 29th St. > San Francisco, CA 94131 > ------------------------------------------------------------------------------- > > -- Greg Stein, http://www.lyra.org/
