On Mon, Dec 14, 2015 at 04:09:01PM -0800, Stefan Beller wrote: > > 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 -- 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