httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: core filters vs non-blocking socket (was Re: Fix for Windows bug#52476)
Date Mon, 13 Aug 2012 13:34:34 GMT
On Mon, Aug 13, 2012 at 9:31 AM, Plüm, Rüdiger, Vodafone Group
<ruediger.pluem@vodafone.com> wrote:
>
>
>> -----Original Message-----
>> From: Joe Orton [mailto:jorton@redhat.com]
>> Sent: Montag, 13. August 2012 14:32
>> To: dev@httpd.apache.org
>> Subject: core filters vs non-blocking socket (was Re: Fix for Windows
>> bug#52476)
>>
>> On Fri, Aug 10, 2012 at 01:31:07PM -0400, Jeff Trawick wrote:
>> > We picked up that apr_socket_opt_set() from the async-dev branch with
>> > r327872, though the timeout calls in there were changed subsequently.
>> > I wonder if that call is stray and it doesn't get along with the
>> > timeout handling on Windows because of the SO_RCVTIMEO/SO_SENDTIMEO
>> > use on Windows, in lieu of non-blocking socket + poll like on Unix.
>> >
>> > At the time it was added, the new code was
>> >
>> > apr_socket_timeout_set(client_socket, 0)
>> > apr_socket_opt_set(client_socket, APR_SO_NONBLOCK, 1)
>> >
>> > (redundant unless there was some APR glitch at the time)
>>
>> Hmmmm, is this right?
>>
>> For event, the listening socket, and hence the accepted socket, is
>> always set to non-blocking in the MPM.
>>
>> For non-event on Unix, the listening socket, and hence the accepted
>> socket, is set to non-blocking IFF there are multiple listeners.
>>
>> So that line is not redundant in the non-event, single listener
>> configuration on Unix... no?
>
> Don't we switch to non-blocking in apr_socket_timeout_set if we set the timeout to 0?

yes

apr_status_t apr_socket_timeout_set(apr_socket_t *sock, apr_interval_time_t t)
{
    apr_status_t stat;

    /* If our new timeout is non-negative and our old timeout was
     * negative, then we need to ensure that we are non-blocking.
     * Conversely, if our new timeout is negative and we had
     * non-negative timeout, we must make sure our socket is blocking.
     * We want to avoid calling fcntl more than necessary on the
     * socket.
     */
    if (t >= 0 && sock->timeout < 0) {
        if (apr_is_option_set(sock, APR_SO_NONBLOCK) != 1) {
            if ((stat = sononblock(sock->socketdes)) != APR_SUCCESS) {
                return stat;
            }
            apr_set_option(sock, APR_SO_NONBLOCK, 1);
        }
    }
    else if (t < 0 && sock->timeout >= 0) {
        if (apr_is_option_set(sock, APR_SO_NONBLOCK) != 0) {
            if ((stat = soblock(sock->socketdes)) != APR_SUCCESS) {
                return stat;
            }
            apr_set_option(sock, APR_SO_NONBLOCK, 0);
        }
    }
   ...

> And if we do a read with a timeout don't we do a poll with a timeout where it does not
> matter whether the socket is blocking or non blocking?

from a high-level, yes; but there is some logic in APR to guess when
data is already available to read, and that requires that the socket
is non-blocking in case the guess is incorrect (that logic is
associated with the APR_INCOMPLETE_READ flag)

>
> Or did I get confused now completely?

no

>
> Regards
>
> Rüdiger
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message