Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <007701c17d41$15ac6390$01000100@sashimi>
From: "Bill Stoddard" <bill@wstoddard.com>
To: "APR Development List" <dev@apr.apache.org>
References: <Pine.GSO.4.32.0112042208090.15453-100000@cobra.cs.Virginia.EDU>
 <054101c17d3c$cbcec500$93c0b0d0@v505>
Subject: Re: Pools rewrite [2]
Date: Tue, 4 Dec 2001 22:58:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> From: "Cliff Woolley" <cliffwoolley@yahoo.com>
> Sent: Tuesday, December 04, 2001 9:12 PM
>
>
> > > 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?
>
> It certainly better not be a problem, or that asych would be borked.
>
> Only one thread -at-a-time- will be processing a request.  Unlike 2.0, there
> might be no thread processing a request at a given time, but the request
> and connection pools can safely be assumed to be thread-safe at any given
> moment, if we do the async right.
>
> Of course, if you implement multi-thread/connection duplexing, then we get
> back to the same code we started with.  And probably loose most of the
> async performance benefits to pool locks.

If the server is doing async network i/o, you will have far fewer threads to contend for
the lock. And the win for an async network i/o server is being able to efficiently handle
large numbers of concurrent clients with just a few threads.

Bill

Bill
>
>
>
>
>