> From: "Cliff Woolley" <[EMAIL PROTECTED]> > 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 > > > > >
