Re: cvs commit: apr-util/include apr_buckets.h
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote: jwoolley2003/07/01 22:25:44 Modified:buckets apr_buckets_alloc.c include apr_buckets.h Log: an addition to the api to allow httpd mpm's to share an apr_allocator_t between a thread pool and the thread's bucket allocator. this will allow the freelist max size to be managed. I just realized there's a problem with this... if you call apr_bucket_alloc_create_ex() and pass it an allocator, alloc_cleanup() should not call apr_allocator_destroy(allocator)... that should be the job of the caller. I'm going to have to add a flag to the apr_bucket_alloc_t to keep track of this. At any rate, the MPM changes in httpd are turning into a lot of ugliness the deeper I dig. Several MPM's create their MPM's in the wrong spot or are in some other way not being cooperative. I'll commit the changes tomorrow to httpd-2.1 anyway, but it's likely to take a week or so to make sure I've not introduced accidentally any double-free conditions on shutdown or memory leaks or anything else bad. I'll need the people who keep up with the MPM's (*all* of them) to test the changes after they're made in 2.1-dev. Bottom line: httpd 2.0.47 should not be held up for this. --Cliff
Re: cvs commit: apr-util/include apr_buckets.h
On Wed, Jul 02, 2003 at 02:03:39AM -0400, Cliff Woolley wrote: On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote: jwoolley2003/07/01 22:25:44 Modified:buckets apr_buckets_alloc.c include apr_buckets.h Log: an addition to the api to allow httpd mpm's to share an apr_allocator_t between a thread pool and the thread's bucket allocator. this will allow the freelist max size to be managed. I just realized there's a problem with this... if you call apr_bucket_alloc_create_ex() and pass it an allocator, alloc_cleanup() should not call apr_allocator_destroy(allocator)... that should be the job of the caller. I'm going to have to add a flag to the apr_bucket_alloc_t to keep track of this. Eh? Why the flag? What is that for... doesn't the caller know when and if he should clean up? So there shouldn't be a need for a flag... Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/include apr_buckets.h
On Tue, 1 Jul 2003, Greg Stein wrote:
Eh? Why the flag? What is that for... doesn't the caller know when and if he
should clean up? So there shouldn't be a need for a flag...
The caller knows. But right now apr_buckets_alloc.c:alloc_cleanup() calls
apr_allocator_destroy(allocator) regardless of whether it owns the
allocator or not.
But I think this is irrelevant because I think there's an entirely cleaner
way to do this. No flag, no extra API function. Namely, we should just
have apr_bucket_alloc_create(apr_pool_t *p) {} use p's allocator always
(apr_pool_allocator_get(p)). I think that will work fine and solve this
problem for good. But I have to think about the ramifications. From what
I've seen of the MPM's in looking through them just now, I think it will
be okay. But I'll need to investigate further to be sure.
--Cliff
