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

[PATCH v3 0/3] reftable: graceful concurrent writes

From
Patrick Steinhardt <ps@pks.im>
Date
Sep 18, 2024, 09:59 UTC
Message-ID
<cover.1726653185.git.ps@pks.im>
In-Reply-To
<cover.1726578382.git.ps@pks.im>
Hi,

this is the third version of my patch series that implements support for graceful concurrent writes with the reftable backend.

There is only a single change compared to v2, namely that we handle `0` and `-1` for the lock timeout config. With `0` we fail immediately, with `-1` we lock indefinitely. This matches semantics of loose and packed ref locking.

Thanks!
Patrick
Patrick Steinhardt (3):
  refs/reftable: introduce "reftable.lockTimeout"
  reftable/stack: allow locking of outdated stacks
  refs/reftable: reload locked stack when preparing transaction
 Documentation/config/reftable.txt |  8 ++++
 refs/reftable-backend.c           | 13 +++++-
 reftable/reftable-stack.h         | 13 +++++-
 reftable/reftable-writer.h        | 11 +++++
 reftable/stack.c                  | 38 ++++++++++++------
 t/t0610-reftable-basics.sh        | 58 ++++++++++++++++++++++++++
 t/unit-tests/t-reftable-stack.c   | 67 ++++++++++++++++++++++++++++++-
 7 files changed, 189 insertions(+), 19 deletions(-)
Range-diff against v2:
1:  700a35df125 ! 1:  77cffd3b1eb refs/reftable: introduce "reftable.lockTimeout"
    @@ Documentation/config/reftable.txt: reftable.geometricFactor::
     +	Whenever the reftable backend appends a new table to the stack, it has
     +	to lock the central "tables.list" file before updating it. This config
     +	controls how long the process will wait to acquire the lock in case
    -+	another process has already acquired it. Default is 100 (i.e., retry
    -+	for 100ms).
    ++	another process has already acquired it. Value 0 means not to retry at
    ++	all; -1 means to try indefinitely. Default is 100 (i.e., retry for
    ++	100ms).
     
      ## refs/reftable-backend.c ##
     @@ refs/reftable-backend.c: static int reftable_be_config(const char *var, const char *value,
    @@ refs/reftable-backend.c: static int reftable_be_config(const char *var, const ch
      			die("reftable geometric factor cannot exceed %u", (unsigned)UINT8_MAX);
      		opts->auto_compaction_factor = factor;
     +	} else if (!strcmp(var, "reftable.locktimeout")) {
    -+		unsigned long lock_timeout = git_config_ulong(var, value, ctx->kvi);
    ++		int64_t lock_timeout = git_config_int64(var, value, ctx->kvi);
    ++		if (lock_timeout > LONG_MAX)
    ++			die("reftable lock timeout cannot exceed %"PRIdMAX, (intmax_t)LONG_MAX);
    ++		if (lock_timeout < 0 && lock_timeout != -1)
    ++			die("reftable lock timeout does not support negative values other than -1");
     +		opts->lock_timeout_ms = lock_timeout;
      	}
      
    @@ reftable/reftable-writer.h: struct reftable_write_options {
     +	 * Note that this does not apply to locking individual tables, as these
     +	 * should only ever be locked when already holding the "tables.list"
     +	 * lock.
    ++	 *
    ++	 * Passing 0 will fail immediately when the file is locked, passing a
    ++	 * negative value will cause us to block indefinitely.
     +	 */
    -+	unsigned lock_timeout_ms;
    ++	long lock_timeout_ms;
      };
      
      /* reftable_block_stats holds statistics for a single block type */
2:  f4be0966e17 = 2:  6130565498e reftable/stack: allow locking of outdated stacks
3:  111b497ef17 = 3:  25d4e513a36 refs/reftable: reload locked stack when preparing transaction
-- 
2.46.0.551.gc5ee8f2d1c.dirty
Previous: James LiuNext: Patrick Steinhardt
Message 20 of 42 in “reftable: graceful concurrent writes”
  1. 0/3 reftable: graceful concurrent writesPatrick Steinhardt, Sep 17, 2024
  2. 1/3 refs/reftable: introduce "reftable.lockTimeout"Patrick Steinhardt, Sep 17, 2024
  3. karthik nayakSep 17, 2024
  4. Eric SunshineSep 17, 2024
  5. Patrick SteinhardtSep 18, 2024
  6. Patrick SteinhardtSep 18, 2024
  7. 2/3 reftable/stack: allow locking of outdated stacksPatrick Steinhardt, Sep 17, 2024
  8. 3/3 refs/reftable: reload locked stack when preparing transactionPatrick Steinhardt, Sep 17, 2024
  9. karthik nayakSep 17, 2024
  10. Patrick SteinhardtSep 18, 2024
  11. 0/3 reftable: graceful concurrent writesPatrick Steinhardt, Sep 18, 2024
  12. 1/3 refs/reftable: introduce "reftable.lockTimeout"Patrick Steinhardt, Sep 18, 2024
  13. James LiuSep 18, 2024
  14. Patrick SteinhardtSep 18, 2024
  15. 2/3 reftable/stack: allow locking of outdated stacksPatrick Steinhardt, Sep 18, 2024
  16. James LiuSep 18, 2024
  17. Patrick SteinhardtSep 18, 2024
  18. 3/3 refs/reftable: reload locked stack when preparing transactionPatrick Steinhardt, Sep 18, 2024
  19. James LiuSep 18, 2024
  20. 0/3 reftable: graceful concurrent writesPatrick Steinhardt, Sep 18, 2024
  21. 1/3 refs/reftable: introduce "reftable.lockTimeout"Patrick Steinhardt, Sep 18, 2024
  22. Junio C HamanoSep 19, 2024
  23. 2/3 reftable/stack: allow locking of outdated stacksPatrick Steinhardt, Sep 18, 2024
  24. Junio C HamanoSep 20, 2024
  25. Patrick SteinhardtSep 24, 2024
  26. 3/3 refs/reftable: reload locked stack when preparing transactionPatrick Steinhardt, Sep 18, 2024
  27. James LiuSep 18, 2024
  28. Patrick SteinhardtSep 24, 2024
  29. 0/3 reftable: graceful concurrent writesPatrick Steinhardt, Sep 24, 2024
  30. 1/3 refs/reftable: introduce "reftable.lockTimeout"Patrick Steinhardt, Sep 24, 2024
  31. 2/3 reftable/stack: allow locking of outdated stacksPatrick Steinhardt, Sep 24, 2024
  32. 3/3 refs/reftable: reload locked stack when preparing transactionPatrick Steinhardt, Sep 24, 2024
  33. Jeff KingSep 27, 2024
  34. Patrick SteinhardtSep 30, 2024
  35. Josh SteadmonSep 30, 2024
  36. Patrick SteinhardtOct 1, 2024
  37. Jeff KingOct 1, 2024
  38. Junio C HamanoOct 1, 2024
  39. Patrick SteinhardtOct 2, 2024
  40. Junio C HamanoOct 1, 2024
  41. Josh SteadmonOct 1, 2024
  42. Jeff KingOct 1, 2024

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.