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

From: Jeff King <peff@peff.net>
Date: Dec 15, 2015, 01:44 UTC
Message-ID: <20151215014456.GA28768@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kbLHNtxcwhZz=tHpJB2XnxMeuEJBG=PmoAbcVF4Wzno2g@mail.gmail.com>

On Mon, Dec 14, 2015 at 04:25:18PM -0800, Stefan Beller wrote:

Show 10 quoted lines

> > But yeah, I think simply using xread() as-is in strbuf_read_once (or
> > whatever it ends up being called) is OK.
> 
> I was actually thinking about using {without-x}read, just the plain system call.
> Do we have any issues with that for wrapping purposes for Windows?
> There is no technical reason to prefer xread over read in strbuf_read_once as
> * we are not nonblocking (so the EAGAIN|| EWOULDBLOCK doesn't apply)
> * we don't care about EINTR and retrying upon that signal
> * we would not care about MAX_IO_SIZE most likely (that's actually one
> of the reasons I could technically think of to prefer xread)

I think you do still need to care about EINTR, or at least not barfing if read() returns -1. If I understand correctly, you want to do something like:

  while (1) {
	poll(some_fds);
	for (i = 0; i < nr_fds; i++) {
		if (some_fds[i].revents & POLLIN) {
			int r = strbuf_read_once(buf[i], some_fds[i]);
			/* ??? what do we do with r? */
		}
	}
  }

If we get EINTR from that read, it's OK for us to loop back to the poll() and go again.

But if we get a true error in "r", we'd want to know, right? That means we must distinguish between EINTR and "real" errors (like EIO or something). We can do that here, but I think it's just as easy to do it inside of strbuf_read_once (by calling xread() there). It's OK not to jump back to the poll(), because we know the data that triggered the POLLIN is still waiting for us to read it.

And we are fine with EAGAIN, too. We don't expect the sockets to be non-blocking in the first place, but even if they were, we know we just got POLLIN, so there should be data waiting.

-Peff