Re: [PATCH 3/8] xread_nonblock: add functionality to read from fds without blocking

From: Jeff King <peff@peff.net>
Date: Dec 15, 2015, 00:16 UTC
Message-ID: <20151215001642.GA26409@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kZGjCy-o=2hO22=4=n2JqUsEG+dqOZFP4Hhf5E72B-_JA@mail.gmail.com>

On Mon, Dec 14, 2015 at 04:09:01PM -0800, Stefan Beller wrote:

Show 12 quoted lines

> > Are we trying to protect ourselves against somebody _else_ giving us a
> > non-blocking descriptor? In that case we'll quietly spin and waste CPU.
> > Which isn't great, but perhaps better than returning an error.
> 
> Yes.
> This sounds like a good reasoning for 2/8 (add in the poll, so we are
> more polite), though.
> 
> This patch is a prerequisite for 4/8, which explicitly doesn't want to loop
> but a quick return. Maybe we could even drop this patch and just use
> `read` as is in 4/8. Looking from a higher level perspective, we don't care
> about strbuf_read_nonblocking to return after a signal without retry.

I was actually thinking about simply teaching xread() not to worry about EAGAIN, but that would probably be a regression in the "whoops, somebody gave us a non-blocking stdin!" case.

But yeah, I think simply using xread() as-is in strbuf_read_once (or whatever it ends up being called) is OK. I think all of the _intentionally_ non-blocking descriptors are gone in this iteration, right? So the caller of strbuf_read_once expects to have to call poll() or to block. And that's what xread() does.

-Peff