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

On Mon, Dec 14, 2015 at 4:16 PM, Jeff King wrote: > 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

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

On Mon, Dec 14, 2015 at 03:15:29PM -0800, Junio C Hamano wrote: > -- >8 -- > From: Stefan Beller > 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

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

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

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

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

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

On Mon, Dec 14, 2015 at 3:57 PM, Jeff King wrote: > On Mon, Dec 14, 2015 at 03:15:29PM -0800, Junio C Hamano wrote: > >> -- >8 -- >> From: Stefan Beller >> Date: Mon, 14 Dec 2015 11:37:13 -0800 >> Subject: [PATCH] xread_nonblock: add functionality to read from

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

Jeff King writes: > 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. I think I said it earlier in a message upthread.

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

Am 15.12.2015 um 01:25 schrieb Stefan Beller: 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? xread() limits the size being read to MAX_IO_SIZE, which is needed on some systems (I think that

[PATCH 3/8] 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. Helped-by: Jacob Keller Helped-by: Jeff King

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

Stefan Beller writes: > 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. Do you still need this

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

On Mon, Dec 14, 2015 at 2:37 PM, Stefan Beller wrote: > 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

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

On Mon, Dec 14, 2015 at 6:03 PM, Eric Sunshine wrote: > On Mon, Dec 14, 2015 at 2:37 PM, Stefan Beller wrote: >> Provide a wrapper to read(), similar to xread(), that restarts on >> EINTR but not EAGAIN (or EWOULDBLOCK). This enables the caller to >>

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

Eric Sunshine writes: > The last sentence is confusing. From the commit message, we learn that > this function doesn't care about EAGAIN or EWOULDBLOCK, yet the above > comment seems to imply that it does. What it really ought to be saying > is that "as a convenience,

[PATCH 3/8] 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. Helped-by: Jacob Keller Helped-by: Jeff King