Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 83305 invoked from network); 1 Mar 2004 06:03:35 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 1 Mar 2004 06:03:35 -0000 Received: (qmail 7319 invoked by uid 500); 1 Mar 2004 06:03:08 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 7292 invoked by uid 500); 1 Mar 2004 06:03:08 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 7276 invoked from network); 1 Mar 2004 06:03:07 -0000 Received: from unknown (HELO scotch.ics.uci.edu) (128.195.24.168) by daedalus.apache.org with SMTP; 1 Mar 2004 06:03:07 -0000 Received: from [10.0.1.91] (pv106211.reshsg.uci.edu [128.195.106.211]) (authenticated bits=0) by scotch.ics.uci.edu (8.12.6/8.12.6) with ESMTP id i2163HcF007660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Feb 2004 22:03:17 -0800 (PST) Date: Sun, 29 Feb 2004 22:03:22 -0800 From: Justin Erenkrantz To: dev@httpd.apache.org Subject: Re: FreeBSD 4.x and Apache2: worker MPM issue Message-ID: <2147483647.1078092202@[10.0.1.92]> In-Reply-To: <20040229153545.M82441@ganymede.hub.org> References: <20040228220424.S82441@ganymede.hub.org> <2147483647.1078009181@[10.0.1.91]> <20040229122848.A82441@ganymede.hub.org> <2147483647.1078045404@[10.0.1.91]> <20040229153545.M82441@ganymede.hub.org> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=unavailable version=2.70-r6256 X-Spam-Checker-Version: SpamAssassin 2.70-r6256 (2004-01-23) on scotch.ics.uci.edu X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --On Sunday, February 29, 2004 4:06 PM -0400 "Marc G. Fournier" wrote: > k, if I'm understanding what you are saying, how do you test something > like that in a way that you can debug it? What I'm reading is that if I > sent two queries (GET / and, say, GET /subdir), there is a chance that the > one that sent GET / will get the results for GET /subdir? No, that's not quite the problem. It is: 1. Client requests GET / 2. *nothing happens* 3. Client (same or different) requests GET /subdir/ 4. Server responds to GET / request issued in #1 (to the correct client) 5. *nothing happens* 6. Someone requests GET /subdir/foo/ issued in #3 7. Server responds to GET /subdir/ request 8. *nothing happens* ...repeat cycle... Does this make more sense? The server won't respond to the first request until the second request is issued and so on. We think it's a flaw in how libc_r implements the pthread condition variables. But, again, it's been fixed with the thread library rewrites in 5.2. -- justin