apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Pools rewrite [2]
Date Wed, 05 Dec 2001 03:24:44 GMT
On Tue, Dec 04, 2001 at 10:12:20PM -0500, Cliff Woolley wrote:
> 
> > This is my second go at the pools code.
> 
> A potential snag with the thread-specific pools idea was brought up today
> when I was talking with FirstBill and some of the others.  What is this
> going to do to us a little ways down the road when we try to implement
> async I/O, and all of the sudden requests are jumping from one thread to
> another?  Sounds like a big problem if thread-specific pools are in
> place... is there an easy answer?

My guess would be not to pass POOL_FNEW_ALLOCATOR to apr_pool_create.
It's an option passed when we create the pool, so if you can't 
guarantee the thread-locality of the pool, it would make sense not to 
split the pool off from its parent.

But, the problem you are describing isn't really a concern to the
pools - it's the use of the pools.  All this does is allow threads
in the same process to allocate memory at the same time (the current
design has a bottleneck where all threads share a common per-process
alloc mutex).  If you control the usage of the pools so that a 
specific pool is only "owned" by one thread at a time, then you 
should be fine even with a per-thread allocator.

I'd really appreciate some explanation on what this async I/O is 
and how it fits into the grand scheme of things.  There are lots 
of assumptions within httpd about things being linear.  -- justin


Mime
View raw message