apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: bucket api patch
Date Fri, 01 Mar 2002 16:11:31 GMT
On Thu, 28 Feb 2002, Brian Pane wrote:

> >(a) calls to apr_bucket_alloc_create() and _destroy() at strategic
> >locations within the MPMs.  I'm hoping that's something one of you guys
> >can help me with, since I haven't exactly spent a lot of time in the MPMs
> >lately.
> I can take on this part for prefork and worker.  One question,
> though: how will apr_bucket_free() work once the real version
> is implemented?  Will it actually free up the space within
> the allocator for reuse, or will it be a no-op?

It is definitely a real _free() and not a noop.  Otherwise we wouldn't get
much for freelists.  :)

> The strategy for placing the apr_bucket_alloc_create() and
> _destroy() calls depends a lot on how apr_bucket_free() works.

The ideas I had in mind go like this:

prefork: create one bucket allocator for each child when the child
         is born, and use that same bucket allocator in every connection
         handled by that child

worker:  similar to prefork, except there can either be one allocator
         per worker thread or one per transaction pool (now that we're
         reusing those pools, might as well associate a bucket allocator
         with each one and reuse those too... don't know if that's a
         benefit or not)

others:  I guess it's one per worker thread?  I know next to nothing
         about these MPMs

Note that the future MPM that does async I/O and passes requests from one
thread to another mid-flight will *have to* have a group of bucket
allocators that it keeps around, assigning an available one to each
*connection* as it comes in -- ie, this one cannot be thread-private
like some of the others might be able to.


   Cliff Woolley
   Charlottesville, VA

View raw message