From dev-return-26956-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Tue Mar 05 22:21:07 2002 Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 71480 invoked by uid 500); 5 Mar 2002 22:21:05 -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 71467 invoked from network); 5 Mar 2002 22:21:05 -0000 Date: Tue, 5 Mar 2002 14:21:11 -0800 From: Aaron Bannert To: dev@httpd.apache.org Subject: Re: cvs commit: httpd-2.0/server/mpm/worker worker.c Message-ID: <20020305142110.G10674@clove.org> Mail-Followup-To: Aaron Bannert , dev@httpd.apache.org References: <20020305211807.3787.qmail@icarus.apache.org> <20020305132226.D10674@clove.org> <20020305140615.F10674@clove.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote: > Aaron Bannert writes: > > > On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: > > > Here is the sequence of events: > > > > > > 1) a thread in child process A is waiting on semaphore > > > 2) graceful restart triggered > > > 3) parent process cleans up the semaphore > > > 4) that thread in child process A gets a failure (EIDRM) from the > > > semaphore obtain and gracefully brings down other threads in child > > > process A > > > > My point is that #3 and #4 are in the wrong order. There should be > > nobody waiting on a semaphore when the parent cleans it up. > > For a graceful restart, the parent can't wait around for all children > to go away before it cleans up and gets the next generation started. > It needs to let worker threads in the old children die gradually as > they finish processing active connection. That process can take a > long time. Will they actually hold the semaphore while they are servicing long-lived connections? I guess we'd have to make it so that as soon as that worker* is done with that connection it checks to see if it is time to quit w/o hitting the semaphore again. Would that work? It still seems weird to me that we're essentially ignoring accept mutex errors during graceful. *"worker" meaning the smallest execution unit required to process a request, defined per-MPM. > (I thought about not cleaning up the semaphore at restart time, but > Greg pointed out that doing so doesn't allow the admin to change the > AcceptMutex foo setting without bringing down the server.) Yeah, that sounds reasonable to me. -aaron