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
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
