On Thu, Sep 17, 2015 at 10:50 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. > 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 -- 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