Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock
- From
Stefan Beller <sbeller@google.com>
- Date
- Sep 17, 2015, 16:51 UTC
- Message-ID
- <CAGZ79kb+GgPaHgVze+q3W99cJ+b2SzdX_DfjLSQCvvLjbDXmbA@mail.gmail.com>
- In-Reply-To
- <CAPc5daVY=t27wkX2x7DSfObwxZuv37VYxi1XD-RKiS1mv4=6KA@mail.gmail.com>
On Thu, Sep 17, 2015 at 9:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> On Thu, Sep 17, 2015 at 9:30 AM, Jeff King <peff@peff.net> wrote: >> >> So I think we would probably want to treat EAGAIN specially: return -1 >> to signal to the caller but _don't_ truncate the strbuf. > > Yeah, "don't truncate" is needed. > >> Arguably we should actually return the number of bytes we _did_ read, >> but then caller cannot easily tell the difference between EOF and >> EAGAIN. > > Why can't it check errno==EAGAIN/EWOULDBLOCK?
Grepping through Gits sources, there are no occurrences of explicitly setting O_NONBLOCK except for the newly introduced spot in the followup patch in run-command (yes we do poll there).
So how would I find out if a fd is blocking or not in the 82 cases of strbuf_read? (Now I naively assume they would all block.)
We could also expose the flags in the API. I think IGNORE_EAGAIN might not be the best now, but rather a NO_TRUNCATE flag would do.