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

Re: [PATCH v2] Refactor recv_sideband()

From
Lukas Fleischer <lfleischer@lfos.de>
Date
Jun 19, 2016, 10:48 UTC
Message-ID
<146633329934.562.6352514848469017860@typhoon>
In-Reply-To
<146597489449.32143.1327156804178869158@s-8d3a2dc3.on.site.uni-stuttgart.de>
On Wed, 15 Jun 2016 at 09:14:54, Lukas Fleischer wrote:
Show 6 quoted lines
> What we could do is reintroduce the local prefix variable I had in v1
> and use that to store whether a prefix needs to be prepended or not. If
> we do that and if we are fine with strbuf memory being (potentially)
> allocated and re-allocated multiple times during a single
> recv_sideband() invocation, the strbuf could be made local to the part
> that actually needs it and could be used as in asprintf().

When I revamped the patch and looked at similar code I had another idea that I did not want to keep to myself:

In contexts similar to this patch, we often seem to use statically allocated string buffers as follows:

-- 8< --
diff --git a/sideband.c b/sideband.c
index 8340a1b..08b75e2 100644
--- a/sideband.c
+++ b/sideband.c
@@ -22,9 +22,10 @@ int recv_sideband(const char *me, int in_stream, int out)
 {
 	const char *term, *suffix;
 	char buf[LARGE_PACKET_MAX + 1];
-	struct strbuf outbuf = STRBUF_INIT;
+	static struct strbuf outbuf = STRBUF_INIT;
 	const char *b, *brk;
 
+	strbuf_reset(&outbuf);
 	strbuf_addf(&outbuf, "%s", PREFIX);
 	term = getenv("TERM");
 	if (isatty(2) && term && strcmp(term, "dumb"))
-- 8< --

The benefits are obvious: No memory (re-)allocation overhead and no need
to take care of freeing on every return path. The downside is that the
function becomes non-thread-safe. After looking at the call sites, it
seems like we do not seem to call recv_sideband() from different threads
yet -- but do we want to rely on that?

The other two options are:

1. As I suggested earlier, introduce a wrapper that could be named
   xwritef() or fprintf_atomic() and allocate a new buffer (i.e., use a
   fresh strbuf) each time something is printed.

2. Keep using a fixed-size buffer size we already know the maximum size
   each of the strings can have.

Which one do you prefer?

Regards,
Lukas
Previous: Nicolas Pitre
Message 60 of 60 in “Refactor recv_sideband()”
  1. Refactor recv_sideband()Lukas Fleischer, Jun 13, 2016
  2. Nicolas PitreJun 13, 2016
  3. Johannes SchindelinJun 14, 2016
  4. Nicolas PitreJun 14, 2016
  5. Johannes SchindelinJun 14, 2016
  6. Nicolas PitreJun 14, 2016
  7. Refactor recv_sideband()Lukas Fleischer, Jun 14, 2016
  8. Lukas FleischerJun 14, 2016
  9. Junio C HamanoJun 14, 2016
  10. Jeff KingJun 15, 2016
  11. Jeff KingJun 24, 2016
  12. Johannes SchindelinJun 24, 2016
  13. Jeff KingJun 24, 2016
  14. Junio C HamanoJun 24, 2016
  15. Lukas FleischerJun 27, 2016
  16. Junio C HamanoJun 27, 2016
  17. Jeff KingJun 27, 2016
  18. Junio C HamanoJun 27, 2016
  19. Lukas FleischerJun 27, 2016
  20. Nicolas PitreJun 27, 2016
  21. Lukas FleischerJun 28, 2016
  22. Junio C HamanoJun 28, 2016
  23. Johannes SchindelinJun 28, 2016
  24. Johannes SchindelinJun 28, 2016
  25. Junio C HamanoJun 28, 2016
  26. Johannes SchindelinJun 28, 2016
  27. Dennis KaarsemakerJun 24, 2016
  28. Refactor recv_sideband()Lukas Fleischer, Jun 22, 2016
  29. Nicolas PitreJun 22, 2016
  30. Nicolas PitreJun 22, 2016
  31. Lukas FleischerJun 23, 2016
  32. Nicolas PitreJun 23, 2016
  33. Refactor recv_sideband()Lukas Fleischer, Jun 28, 2016
  34. Junio C HamanoJun 28, 2016
  35. Junio C HamanoJun 28, 2016
  36. Nicolas PitreJun 28, 2016
  37. Junio C HamanoJun 28, 2016
  38. Nicolas PitreJun 28, 2016
  39. Junio C HamanoJun 28, 2016
  40. Nicolas PitreJun 28, 2016
  41. Junio C HamanoJun 28, 2016
  42. Nicolas PitreJun 28, 2016
  43. Junio C HamanoJun 28, 2016
  44. Junio C HamanoJun 28, 2016
  45. Junio C HamanoJun 29, 2016
  46. Nicolas PitreJun 29, 2016
  47. Nicolas PitreJun 29, 2016
  48. Junio C HamanoJun 29, 2016
  49. Lukas FleischerJun 30, 2016
  50. Junio C HamanoJul 1, 2016
  51. Nicolas PitreJul 5, 2016
  52. Junio C HamanoJul 6, 2016
  53. Nicolas PitreJul 7, 2016
  54. Nicolas PitreJun 14, 2016
  55. Nicolas PitreJun 14, 2016
  56. Junio C HamanoJun 14, 2016
  57. Lukas FleischerJun 14, 2016
  58. Junio C HamanoJun 14, 2016
  59. Nicolas PitreJun 14, 2016
  60. Lukas FleischerJun 19, 2016

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.