Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 11476 invoked by uid 500); 5 Dec 2001 11:50:23 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 11464 invoked from network); 5 Dec 2001 11:50:23 -0000 From: "Sander Striker" To: "Cliff Woolley" Cc: Subject: RE: Pools rewrite [2] Date: Wed, 5 Dec 2001 12:52:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal X-Rcpt-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Cliff Woolley [mailto:cliffwoolley@yahoo.com] > Sent: 05 December 2001 04:12 >> 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? > > --Cliff The app decides if a pool is thread specific, or put differently, if a pool will be used only by one thread at a time. The default behaviour of the new pools code is to behave the exact same way as the original pools code. Sander