Re: [PATCH v12 04/20] index-helper: new daemon for caching index and related stuff
- From
David Turner <novalis@novalis.org>
- Date
- Jun 26, 2016, 17:49 UTC
- Message-ID
- <577015C5.8070407@novalis.org>
- In-Reply-To
- <20160626085347.GA4053@dcvr.yhbt.net>
On 06/26/2016 04:53 AM, Eric Wong wrote:
Show 24 quoted lines
> 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?