Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <45103012.6030803@rowe-clan.net>
Date: Tue, 19 Sep 2006 12:59:46 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: svn commit: r442492 -
 /apr/apr/branches/1.2.x/network_io/unix/sockets.c
References: <20060912065935.9BDA11A981A@eris.apache.org>
 <20060913123006.GA32224@redhat.com> <20060919161731.GA15564@redhat.com>
In-Reply-To: <20060919161731.GA15564@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Joe Orton wrote:
> On Wed, Sep 13, 2006 at 01:30:06PM +0100, Joe Orton wrote:
>> On Tue, Sep 12, 2006 at 06:59:35AM -0000, Mladen Turk wrote:
>>> Author: mturk
>>> Date: Mon Sep 11 23:59:34 2006
>>> New Revision: 442492
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=442492
>>> Log:
>>> Backport r442135 from trunk.
>> This has broken the access control tests in httpd-test for both 2.2.x 
>> and 2.0.x.  I'm seeing random addresses logged in access_log, 0.0.0.0 
>> and such.  The ->remote_addr changes below look unrelated to the 
>> original change, and I guess that is what is wrong.
> 
> I've fixed this but I still have far less confidence in these changes 
> than would warrant putting them in 0.9.x/1.2.x.  IMO revert the branch 
> changes and just leave this on the trunk to soak for a bit.

Yes - please do.  One aspect of this patch I strongly dislike is the fact
that it's much less efficient.  If the pool associated with the soon-to-be
allocated apr_socket_t would be destroyed on accept failure (the TYPICAL
design paradigm) there's no reason to avoid this allocation, and we've
watched sa buffers grow as the network layer has become richer (e.g. IPV6)
which makes stack a suboptimal place to place such buffers.