On 06/26/2016 04:53 AM, Eric Wong wrote:
David Turner <novalis@xxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html