Re: [PATCH 3/8] xread_nonblock: add functionality to read from fds without blocking
- From
Stefan Beller <sbeller@google.com>
- Date
- Dec 15, 2015, 00:09 UTC
- Message-ID
- <CAGZ79kZGjCy-o=2hO22=4=n2JqUsEG+dqOZFP4Hhf5E72B-_JA@mail.gmail.com>
- In-Reply-To
- <20151214235736.GA26133@sigill.intra.peff.net>
On Mon, Dec 14, 2015 at 3:57 PM, Jeff King <peff@peff.net> wrote:
Show 17 quoted lines
> On Mon, Dec 14, 2015 at 03:15:29PM -0800, Junio C Hamano wrote: > >> -- >8 -- >> From: Stefan Beller <sbeller@google.com> >> Date: Mon, 14 Dec 2015 11:37:13 -0800 >> Subject: [PATCH] xread_nonblock: add functionality to read from fds without blocking >> >> Provide a wrapper to read(), similar to xread(), that restarts on >> EINTR but not EAGAIN (or EWOULDBLOCK). This enables the caller to >> handle polling itself, possibly polling multiple sockets or performing >> some other action. > > This makes me wonder why we restart xread() on EAGAIN in the first > place. > > On EINTR, sure; signals can come and we want to keep going. But if do > not have non-blocking descriptors, it should never happen, right?
right.
> > 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.
> > -Peff