All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: karthik nayak <karthik.188@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	James Liu <james@jamesliu.io>
Subject: [PATCH v3 0/3] reftable: graceful concurrent writes
Date: Wed, 18 Sep 2024 11:59:24 +0200	[thread overview]
Message-ID: <cover.1726653185.git.ps@pks.im> (raw)
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


  parent reply	other threads:[~2024-09-18  9:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-17 13:43 [PATCH 0/3] reftable: graceful concurrent writes Patrick Steinhardt
2024-09-17 13:43 ` [PATCH 1/3] refs/reftable: introduce "reftable.lockTimeout" Patrick Steinhardt
2024-09-17 17:46   ` karthik nayak
2024-09-17 17:50     ` Eric Sunshine
2024-09-18  4:31       ` Patrick Steinhardt
2024-09-18  4:31     ` Patrick Steinhardt
2024-09-17 13:43 ` [PATCH 2/3] reftable/stack: allow locking of outdated stacks Patrick Steinhardt
2024-09-17 13:43 ` [PATCH 3/3] refs/reftable: reload locked stack when preparing transaction Patrick Steinhardt
2024-09-17 18:26 ` [PATCH 0/3] reftable: graceful concurrent writes karthik nayak
2024-09-18  4:31   ` Patrick Steinhardt
2024-09-18  4:32 ` [PATCH v2 " Patrick Steinhardt
2024-09-18  4:32   ` [PATCH v2 1/3] refs/reftable: introduce "reftable.lockTimeout" Patrick Steinhardt
2024-09-18  9:22     ` James Liu
2024-09-18  9:39       ` Patrick Steinhardt
2024-09-18  4:32   ` [PATCH v2 2/3] reftable/stack: allow locking of outdated stacks Patrick Steinhardt
2024-09-18  9:26     ` James Liu
2024-09-18  9:39       ` Patrick Steinhardt
2024-09-18  4:32   ` [PATCH v2 3/3] refs/reftable: reload locked stack when preparing transaction Patrick Steinhardt
2024-09-18  9:33   ` [PATCH v2 0/3] reftable: graceful concurrent writes James Liu
2024-09-18  9:59 ` Patrick Steinhardt [this message]
2024-09-18  9:59   ` [PATCH v3 1/3] refs/reftable: introduce "reftable.lockTimeout" Patrick Steinhardt
2024-09-19 21:34     ` Junio C Hamano
2024-09-18  9:59   ` [PATCH v3 2/3] reftable/stack: allow locking of outdated stacks Patrick Steinhardt
2024-09-20 18:10     ` Junio C Hamano
2024-09-24  5:33       ` Patrick Steinhardt
2024-09-18  9:59   ` [PATCH v3 3/3] refs/reftable: reload locked stack when preparing transaction Patrick Steinhardt
2024-09-18 23:23   ` [PATCH v3 0/3] reftable: graceful concurrent writes James Liu
2024-09-24  5:33     ` Patrick Steinhardt
2024-09-24  5:32 ` [PATCH v4 " Patrick Steinhardt
2024-09-24  5:33   ` [PATCH v4 1/3] refs/reftable: introduce "reftable.lockTimeout" Patrick Steinhardt
2024-09-24  5:33   ` [PATCH v4 2/3] reftable/stack: allow locking of outdated stacks Patrick Steinhardt
2024-09-24  5:33   ` [PATCH v4 3/3] refs/reftable: reload locked stack when preparing transaction Patrick Steinhardt
2024-09-27  4:07     ` Jeff King
2024-09-30  6:49       ` Patrick Steinhardt
2024-09-30 22:19       ` Josh Steadmon
2024-10-01  4:27         ` Patrick Steinhardt
2024-10-01 22:54           ` Jeff King
2024-10-01 23:24             ` Junio C Hamano
2024-10-02 10:58               ` Patrick Steinhardt
2024-10-01  7:34         ` Junio C Hamano
2024-10-01 18:53           ` Josh Steadmon
2024-10-01 19:08             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1726653185.git.ps@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=james@jamesliu.io \
    --cc=karthik.188@gmail.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.