Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
From: "Sander Striker" <striker@apache.org>
To: <dev@apr.apache.org>
Subject: RE: Pools rewrite [2]
Date: Wed, 5 Dec 2001 13:05:02 +0100
Message-ID: <JLEGKKNELMHCJPNMOKHOMEHIEPAA.striker@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20011205032444.GC22835@ebuilt.com>
Importance: Normal

> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: 05 December 2001 04:25

> 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.

Actually, that depends.  One option is to not specify POOL_FNEW_ALLOCATOR
at all.  The second option, if you know the pool is going to be shared by
threads but not much, pass POOL_FNEW_ALLOCATOR|POOL_FLOCK.  Now, the pool
will have its own allocator (which subpools will inherit) which is protected
by a mutex.  This is a different mutex than the one on the parent pool,
so 'fighting over' mutexes would be less likely.
 
> 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.

Indeed.  Currently the allocator is hidden away behind the pools API,
we could opt to expose it.

> 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

Sander