apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Pools rewrite [2]
Date Wed, 05 Dec 2001 04:09:11 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

The idea is to never allow your threads to block doing network i/o. Do all your
reads/writes with non-blocking (or asynchronous) i/o. Your worker threads are blocked on a
queue (BSD KQueue, Solaris /dev/poll or Windows CompletionPort) waiting for i/o completion
notifications. When an i/o completes, the queue dispatches one of your threads, you
recover the request context (conn_rec, request_rec, et. al.) with a look-up function keyed
to the file descriptor (or other keys supported by the particular implementation), and
pick up where you left off.  Details of how to recover context, how threads are awakened,
etc. are a bit different for each OS but the general idea is the same. I expect it is
possible to create an APR API that hides most if not all of the OS specific implementation

Since your worker threads never block on network i/o, they are free to handle other work,
thus you can handle more work with fewer threads (and all the good things that implies).


View raw message