Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 15880 invoked by uid 6000); 1 Nov 1997 21:27:00 -0000 Received: (qmail 15873 invoked from network); 1 Nov 1997 21:26:58 -0000 Received: from twinlark.arctic.org (204.62.130.91) by taz.hyperreal.org with SMTP; 1 Nov 1997 21:26:58 -0000 Received: (qmail 26877 invoked by uid 500); 1 Nov 1997 21:33:34 -0000 Date: Sat, 1 Nov 1997 13:33:33 -0800 (PST) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: night of the dead Apache In-Reply-To: <9710312047.aa24357@paris.ics.uci.edu> Message-ID: Organization: Transmeta Corp. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Oh goddamn, the pthread standard sucks. Look at this, this is from the single unix specification (dig around on www.opengroup.com to find it, it's essentially the posix spec): Thread termination does not release any application visible process resources, including, but not limited to, mutexes and file descriptors, nor does it perform any process level cleanup actions, including, but not limited to, calling any atexit() routines that may exist But all may not be lost. We can mask every signal except TERM, HUP, and USR1 while we're in the critical section (and KILL of course). Then we can properly release the mutex on receipt of those signals. This would add two syscalls to the pthread case, and probably drop its performance to something closer to fcntl() anyhow. I'll go find my timing program and make this change and post back. Dean On Fri, 31 Oct 1997, Roy T. Fielding wrote: > >Is it possible that the parent is killing off the only child > >that has the mutex lock, and that killing it doesn't free the lock? > >... > >which kills off the two children that were created during the > >big sequence (not trussed). One of those two had the mutex. > >Hmmm, time to test USE_PTHREAD_SERIALIZED_ACCEPT. > > Yup, that's the problem. Changing back to USE_FCNTL_SERIALIZED_ACCEPT > fixes it. The fcntl mutex is unlocked when the child is killed, whereas > the pthreads mutex appears to remain locked. I'm not sure if we should > try to fix it or just remove the code. Dean? Basically, we'd need > a way to check in the child's HUP/USR1 handler whether or not it has the > mutex and unlock it if it does. > > ....Roy >