Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17874 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4042 invoked by uid 1010); 12 Aug 2005 16:16:15 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 4027 invoked from network); 12 Aug 2005 16:16:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Aug 2005 16:16:15 -0000 X-Host-Fingerprint: 204.11.219.140 lt1.firehawksystems.com Linux 2.4/2.6 Received: from ([204.11.219.140:51320] helo=lt1.firehawksystems.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id D4/91-33075-E4BCCF24 for ; Fri, 12 Aug 2005 12:16:14 -0400 Received: from [10.0.0.2] ([69.219.239.6]) (authenticated bits=0) by lt1.firehawksystems.com (8.13.3/8.13.3) with ESMTP id j7CGG4hT006741 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 12 Aug 2005 09:16:06 -0700 In-Reply-To: <57792e85050812085214e0b260@mail.gmail.com> References: <57792e85050808205143e96a8f@mail.gmail.com> <42F907A0.8070900@web.de> <57792e85050809142416ee5d6c@mail.gmail.com> <42F9217F.6010604@lerdorf.com> <57792e8505080917402f144072@mail.gmail.com> <42F962CF.4000503@lerdorf.com> <57792e85050811174867b7a6c3@mail.gmail.com> <57792e85050812085214e0b260@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: Content-Transfer-Encoding: 7bit Cc: Andreas Korthaus , Rasmus Lerdorf , internals@lists.php.net Date: Fri, 12 Aug 2005 11:15:59 -0500 To: steve roussey X-Mailer: Apple Mail (2.622) X-Virus-Scanned: ClamAV version 0.86.1, clamav-milter version 0.86 on lt1 X-Virus-Status: Clean Subject: Re: [PHP-DEV] Re: Moving to PHP5.1 and Apache 2.2 next year, need help From: list@firehawksystems.com ("Brian J. France") On Aug 12, 2005, at 10:52 AM, steve roussey wrote: > On 8/12/05, Brian J. France wrote: >> Really? We just did a around of discussion/debugging on this at work >> and I found that it uses ap_lingering_close which is like the >> lingering_close function in 1.3. > > :) > > Yes, it does do ap_lingering_close, and it sets SO_LINGER. I have no > idea why they do both, I only assume they know what they are doing and > it works out for the best. I see the code for SO_LINGER in apr_socket_opt_set, but I don't see any place in the server code that calls apr_socket_opt_set with APR_SO_LINGER. Running gdb I see APR_SO_KEEPALIVE, APR_SO_REUSEADDR and APR_TCP_NODELAY passed to apr_socket_opt_set but not APR_SO_LINGER. (This is based on the svn of httpd with no changes) > I'm surprised it is an ap call and not an apr call, but > I am not a web server programmer! I agree, it took me a while to find the call again because I keep searching for apr_. Brian