You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <jw...@virginia.edu> on 2003/07/02 08:03:39 UTC
Re: cvs commit: apr-util/include apr_buckets.h
On Wed, 2 Jul 2003 jwoolley@apache.org wrote:
> jwoolley 2003/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
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Re: cvs commit: apr-util/include apr_buckets.h
Posted by Cliff Woolley <jw...@virginia.edu>.
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
Re: cvs commit: apr-util/include apr_buckets.h
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jul 02, 2003 at 02:03:39AM -0400, Cliff Woolley wrote:
> On Wed, 2 Jul 2003 jwoolley@apache.org wrote:
>
> > jwoolley 2003/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
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jul 02, 2003 at 02:03:39AM -0400, Cliff Woolley wrote:
> On Wed, 2 Jul 2003 jwoolley@apache.org wrote:
>
> > jwoolley 2003/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/