Received: by taz.hyperreal.com (8.8.3/V2.0) id MAA28750; Tue, 14 Jan 1997 12:20:21 -0800 (PST) Received: from battra.telebase.com by taz.hyperreal.com (8.8.3/V2.0) with ESMTP id MAA28745; Tue, 14 Jan 1997 12:20:18 -0800 (PST) Received: from wormhole.telebase.com (root@[172.16.2.129]) by battra.telebase.com (8.8.3/8.8.1) with ESMTP id PAA15369 for ; Tue, 14 Jan 1997 15:20:16 -0500 (EST) Received: from spudboy.telebase.com (spudboy.telebase.com [172.16.2.215]) by wormhole.telebase.com (8.8.3/8.8.1) with ESMTP id PAA22839 for ; Tue, 14 Jan 1997 15:20:15 -0500 (EST) Received: (from chuck@localhost) by spudboy.telebase.com (8.8.1/8.8.1) id PAA26870 for new-httpd@hyperreal.com; Tue, 14 Jan 1997 15:20:15 -0500 (EST) From: Chuck Murcko Message-Id: <199701142020.PAA26870@spudboy.telebase.com> Subject: Re: lingering_close To: new-httpd@hyperreal.com Date: Tue, 14 Jan 1997 15:20:15 -0500 (EST) In-Reply-To: from "Marc Slemko" at Jan 14, 97 12:38:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com Marc Slemko liltingly intones: > > On Tue, 14 Jan 1997, Randy Terbush wrote: > > > We currently _aren't_ calling lingering_close() in timeout(). > > I'm of the opinion that we should be. We call blclose() which > > is closing the socket. We then longjump back to child_main() > > where I _think_ that we are calling lingering_close() which > > leads to the "Invalid argument" error coming from the error > > code I added to the first shutdown() call in lingering_close(). > > I can't comment on where what is being done and where what should be done > since I don't have the time to look through the code right now, but I > iff NO_LINGCLOSE helps, then the problem is not likely to be due to not > using lingering_close() in timeout() because we didn't do that > before because it didn't exist before and it did work fine for > people that are now haveing problems. That doesn't necessarily > mean what we are doing now is right or shouldn't be changed. > Well, it looks like Randy's correct, from what I read in the code. OTOH, what you say is true, too. The syndrome I see with 40-50 hits/sec testing at home is that the server looks like it's closing everything, or nearly so. That doesn't look right. > Keep in mind that we may be seeing multiple problems here, since some > don't seem to be helped by NO_LINGCLOSE. > Yep. It's possible the patch I mentioned helps SGI folks who set -DNO_LINGCLOSE. *Heeeeey*. What happens if you use -DUSE_SO_LINGER with -DNO_LINGCLOSE? The lingering close was supposed to replace using the socket option. I think one or the other should be defined, but not both or neither. I'll try this at home tonight. chuck Chuck Murcko N2K Inc. Wayne PA chuck@telebase.com And now, on a lighter note: "This process can check if this value is zero, and if it is, it does something child-like." -- Forbes Burkowski, Computer Science 454