Date: Mon, 17 Feb 1997 12:56:45 -0700 (MST)
From: Marc Slemko <marcs@znep.com>
To: new-httpd@hyperreal.com
Subject: Re: lingering_close and performance
In-Reply-To: <Pine.SGI.3.95.970215112704.11309A-200000@fully.organic.com>
Message-ID: <Pine.BSF.3.95.970217124434.12038B-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On Mon, 17 Feb 1997, Ed Korthof wrote:

> Sorry I've been uninvolved for the past week and a half; I've been too
> busy to deal with the topics going on effectively.  I like the solutions
> to the lingering_close problem which I've seen discussed here; for all
> that I think the performance hit is a potential problem (20% is not
> overstating it under certain conditions), functionality is also relevant. 
> 
> One thing comes to mind about the SIGHUP problem I've been seeing -- it
> appears that it may go away when Apache is compiled with NO_LINGCLOSE.  I
> can't test this easily, because none of the servers I administer have
> sufficient relative traffic (this problem was easy to reproduce under high
> traffic, but almost non-existent under low traffic).  But someone (I can't
> seem to find the mail) mentioned possible problems in some version of
> lingering_close, and I figured I'd mention it.  If there was a problem in
> l_c where SIGHUP was blocked, this would explain why and when the bug
> occured, as well as why it isn't reproducible except under high load.

I don't think a HUP should be blocked by anyting l_c is doing.  In any
case, I see the same problem with 1.1.  We _shouldn't_ be loosing signals
from what I understand, but if the OS is it would make sense that it
happens when there are many more children running.  I have never had a
case where a second HUP to the child didn't fix it.  Would be interesting
to add some debugging to my kernel to trace what processes signals are
sent to.  I would not be suprised to learn that the cause of the problem
is something else, but....