Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <495E8C1A.9050908@apache.org>
Date: Fri, 02 Jan 2009 22:50:18 +0100
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r730835 - /httpd/httpd/trunk/server/core.c
References: <20090102200900.6204A23889A0@eris.apache.org>
 <495E85B0.9040700@apache.org> <495E86D3.4080309@rowe-clan.net>
In-Reply-To: <495E86D3.4080309@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


On 01/02/2009 10:27 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> Otherwise the table will not be empty anymore in the case that
>> neither APR_HAS_SO_ACCEPTFILTER nor APR_TCP_DEFER_ACCEPT is set.
> 
> Uhm ... huh?  What gave you the idea that APR_TCP_DEFER_ACCEPT
> is a volatile?  It's present in apr 1.3 (our baseline) and will
> be sticking around into the foreseeable future.
> 
> It is neither a HAS nor HAVE feature flag.  In fact it's the reason
> I started refactoring this code, it was complete twaddle.

Ahh, sorry I missed this point. I guess in this case the #ifdef from the
following code in listen.c should also go away:


#ifdef APR_TCP_DEFER_ACCEPT
        rv = apr_socket_opt_set(s, APR_TCP_DEFER_ACCEPT, 30);
        if (rv != APR_SUCCESS && !APR_STATUS_IS_ENOTIMPL(rv)) {
            ap_log_perror(APLOG_MARK, APLOG_WARNING, rv, p,
                              "Failed to enable APR_TCP_DEFER_ACCEPT");
        }
#endif


Regards

Rüdiger