From: David Turner <novalis@novalis.org>
Date: Sun, 26 Jun 2016 17:49:57 GMT
Subject: Re: [PATCH v12 04/20] index-helper: new daemon for caching index and related stuff
Message-ID: <577015C5.8070407@novalis.org>
In-Reply-To: <20160626085347.GA4053@dcvr.yhbt.net>

On 06/26/2016 04:53 AM, Eric Wong wrote:
> David Turner <novalis@novalis.org> wrote:
>> On 06/25/2016 10:33 AM, Duy Nguyen wrote:
>>>> +               /*
>>>> +                * Our connection to the client is blocking since a client
>>>> +                * can always be killed by SIGINT or similar.
>>>> +                */
>>>> +               set_socket_blocking_flag(client_fd, 0);
>>>
>>> Out of curiosity, do we really need this? I thought default behavior
>>> was always blocking (and checked linux kernel, it seemed to agree with
>>> me). Maybe for extra safety because other OSes may default to
>>> something else?
>>
>> Yes -- see this bug report for details:
>> https://bugs.python.org/issue7995
>
> I realize it's an issue with BSDs, but it still seems
> unnecessary, here:
>
> 1) the packet_read => get_packet_data => read_in_full => xread
>     call chain already poll()s on EAGAIN/EWOULDBLOCK.
>     write_in_full => xwrite busy loops on EAGAIN/EWOULDBLOCK.
>     xwrite should probably poll, too; but I guess EAGAIN is
>     uncommon with small writes.

That is a CPU-burning busy loop on a non-blocking socket.

> 2) you create the listen fd you call accept on and never set
>     non-blocking on it.  It might be an issue one day if
>     we use socket activation and inherit a socket, but the
>     retries mentioned in 1) should cover that case.

Hm.  I wonder why I thought I had made it non-blocking.

I'm sort of reluctant to change this as I no longer have a Mac to test 
on.  Does someone else have a Mac that they can use to test this?