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 03:58:17 GMT
> 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
>
>
>
>
>


Mime
View raw message