Re: [PATCHv3 02/11] run-command: report failure for degraded output just once

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 5, 2015, 02:05 UTC
Message-ID: <xmqqvb9h8ale.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20151104225618.GA18805@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> So I'm not sure I see why we need to be non-blocking at all here, if we
> are correctly hitting poll() and doing a single read on anybody who
> claims to be ready (rather than trying to soak up all of their available
> data), then we should never block, and we should never starve one
> process (even without blocking, we could be in a busy loop slurping from
> A and starve B, but by hitting the descriptors in round-robin for each
> poll(), we make sure they all progress).
>
> What am I missing?

I've always assumed that the original reason why we wanted to set the fd to nonblock was because poll(2) only tells us there is something to read (even a single byte), and the xread_nonblock() call strbuf_read_once() makes with the default size of 8KB is allowed to consume all available bytes and then get stuck waiting for the remainder of 8KB before returning.

If the read(2) in xread_nonblock() always returns as soon as we receive as much as there is data available without waiting for any more, ignoring the size of the buffer (rather, taking the size of the buffer only as the upper bound), then there is no need for nonblock anywhere.

So perhaps the original reasoning of doing nonblock was faulty, you are saying?