From dev-return-45374-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Thu Dec 09 14:33:17 2004 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 44263 invoked from network); 9 Dec 2004 14:33:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 9 Dec 2004 14:33:17 -0000 Received: (qmail 41294 invoked by uid 500); 9 Dec 2004 14:33:10 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 41232 invoked by uid 500); 9 Dec 2004 14:33:10 -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 41209 invoked by uid 99); 9 Dec 2004 14:33:10 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from i.meepzor.com (HELO Boron.MeepZor.Com) (204.146.167.214) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Dec 2004 06:33:08 -0800 Received: from remulak.net (user-10lfdgn.cable.mindspring.com [65.87.182.23]) by Boron.MeepZor.Com (8.12.8/8.12.8) with ESMTP id iB9EW7wE016649 for ; Thu, 9 Dec 2004 09:32:07 -0500 Message-ID: <41B85DEE.5080702@remulak.net> Date: Thu, 09 Dec 2004 09:15:10 -0500 From: Greg Ames User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: fdqueue in Worker MPM References: <1102372788.4631.217.camel@dragon.cnet.cnwk.com> In-Reply-To: <1102372788.4631.217.camel@dragon.cnet.cnwk.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Ronald Park wrote: > I have a few question about fdqueue in the Worker MPM. > > First off, is it really a queue? Looks like a stack to me: last > in == first out. right > This could lead to starvation, no? no. The listener thread blocks if there aren't any idle workers. An advantage of using a FIFO is that it improves the odds that the variables for the current socket/connection will be "cache hot" (i.e. present in the CPU's L1 data cache) when the worker thread runs. > Second: how does ap_queue_push truly block on a full 'queue' (as > it says it does in the comment)? The comment was out of date. I just fixed it. Thanks! Once upon a time, the comment was accurate. But then we realized that accept()ing a new connection, then blocking on the queue was a bad thing because it causes unnecessary latency. Another process with some idle worker threads could be processing the new connection sooner. So we split it up. The current worker MPM reserves a worker thread, blocking if necessary, then issues accept(), then pushes the new connection into the queue to dispatch a worker. The event MPM works the same way for new connections and also uses this machinery to dispatch workers for old connections, for example after waiting for a second request on a keepalive connection. > I see blocking for the big mutex > but nothing that checks and blocks on the queue being full. And > without that, isn't it possible for push to go out of bounds? Take a look at ap_queue_info_wait_for_idler() Greg