Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock
- From
Stefan Beller <sbeller@google.com>
- Date
- Sep 17, 2015, 17:53 UTC
- Message-ID
- <CAGZ79kYKD6e=JmeFgbqHRmDAb1W3jraBayWHjA=-D+SXzubULw@mail.gmail.com>
- In-Reply-To
- <20150917175008.GA29601@sigill.intra.peff.net>
On Thu, Sep 17, 2015 at 10:50 AM, Jeff King <peff@peff.net> wrote:
Show 14 quoted lines
> On Thu, Sep 17, 2015 at 10:45:40AM -0700, Stefan Beller wrote: > >> > You _can_ loop on read until you hit EAGAIN, but I think in general you >> > shouldn't; if you get a lot of input on this fd, you'll starve all of >> > the other descriptors you're polling. You're better off to read a >> > finite amount from each descriptor, and then check again who is ready to >> > read. >> >> That's what I do with the current implementation. Except it's not as clear and >> concise as I patched it into the strbuf_read. > > Is it? I thought the implementation you posted bumped the existing > strbuf_read to strbuf_buf_internal, including the loop. So as long as we > are not getting EAGAIN, it will keep reading forever.
You'll get EAGAIN pretty fast though, as all you do is reading as fast as you can.
Show 5 quoted lines
> Actually not quite > true, as any read shorter than 8192 bytes will cause us to jump out of > the loop, too, but if we assume that the caller is feeding us data > faster than we can read it, we'll never exit strbuf_read_nonblock() and > serve any of the other descriptors.
I see the difference now. That makes sense.
> > -Peff