git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 4/8] strbuf: add strbuf_read_once to read without blocking

From
Stefan Beller <sbeller@google.com>
Date
Dec 14, 2015, 23:27 UTC
Message-ID
<CAGZ79kZK6+f972kF5jx11hjviW3cKtR7xsdw3dYXS48XnC1UqQ@mail.gmail.com>
In-Reply-To
<CAPig+cQUGCFZnOxjuFaYNNhLqfdS7thrUQKqNkr5=0Hr4OkyMw@mail.gmail.com>
On Mon, Dec 14, 2015 at 3:16 PM, Eric Sunshine <ericsunshine@gmail.com> wrote:
Show 24 quoted lines
> On Mon, Dec 14, 2015 at 2:37 PM, Stefan Beller <sbeller@google.com> wrote:
>> The new call will read from a file descriptor into a strbuf once. The
>> underlying call xread_nonblock is meant to execute without blocking if
>> the file descriptor is set to O_NONBLOCK. It is a bug to call
>> strbuf_read_once on a file descriptor which would block.
>>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> ---
>> diff --git a/strbuf.h b/strbuf.h
>> @@ -367,6 +367,14 @@ extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
>>  extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
>>
>>  /**
>> + * Returns the number of new bytes appended to the sb.
>> + * Negative return value signals there was an error returned from
>> + * underlying read(2), in which case the caller should check errno.
>> + * e.g. errno == EAGAIN when the read may have blocked.
>> + */
>> +extern ssize_t strbuf_read_once(struct strbuf *, int fd, size_t hint);
>
> strbuf_read_once() is a rather opaque name; without reading the
> documentation, it's difficult to figure out what it means. I wonder if
> strbuf_read_nonblock() or something would be clearer?

Well the underlying read call can block if the fd is not marked for nonblocking, so I would not name it _nonblock. I just realize this same argument would make the naming moot for the previous patch though. (xread_nonblock may block if not marked unblocking)

Currently we really want is a read once and do not try to grab as much as possible, but just return quickly. We do not do the non blocking setup, as we deemed that unneeded because of the preceding poll in a higher layer to signal we have data there to read.

Junio suggested in the discussion [4/8] maybe we can just use xread and strbuf_read in this series, so I am tempted to drop patches {3,4}/8 as that makes sense to me. For non blocking stuff we can later re introduce those helper functions though.

Previous: Eric SunshineNext: Stefan Beller
Message 22 of 30 in “Rerolling sb/submodule-parallel-fetch for the time after 2.7”
  1. 0/8 Rerolling sb/submodule-parallel-fetch for the time after 2.7Stefan Beller, Dec 14, 2015
  2. 1/8 submodule.c: write "Fetching submodule <foo>" to stderrStefan Beller, Dec 14, 2015
  3. 2/8 xread: poll on non blocking fdsStefan Beller, Dec 14, 2015
  4. Eric SunshineDec 14, 2015
  5. Stefan BellerDec 14, 2015
  6. Junio C HamanoDec 14, 2015
  7. Stefan BellerDec 14, 2015
  8. 3/8 xread_nonblock: add functionality to read from fds without blockingStefan Beller, Dec 14, 2015
  9. Junio C HamanoDec 14, 2015
  10. Eric SunshineDec 14, 2015
  11. Eric SunshineDec 14, 2015
  12. Junio C HamanoDec 14, 2015
  13. Jeff KingDec 14, 2015
  14. Stefan BellerDec 15, 2015
  15. Jeff KingDec 15, 2015
  16. Stefan BellerDec 15, 2015
  17. Jeff KingDec 15, 2015
  18. Johannes SixtDec 15, 2015
  19. Junio C HamanoDec 15, 2015
  20. 4/8 strbuf: add strbuf_read_once to read without blockingStefan Beller, Dec 14, 2015
  21. Eric SunshineDec 14, 2015
  22. Stefan BellerDec 14, 2015
  23. 5/8 sigchain: add command to pop all common signalsStefan Beller, Dec 14, 2015
  24. 6/8 run-command: add an asynchronous parallel child processorStefan Beller, Dec 14, 2015
  25. Johannes SixtDec 14, 2015
  26. Stefan BellerDec 14, 2015
  27. 7/8 fetch_populated_submodules: use new parallel job processingStefan Beller, Dec 14, 2015
  28. 8/8 submodules: allow parallel fetching, add tests and documentationStefan Beller, Dec 14, 2015
  29. Johannes SixtDec 14, 2015
  30. Junio C HamanoDec 14, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.