All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  karthik nayak <karthik.188@gmail.com>,
	 Eric Sunshine <sunshine@sunshineco.com>,
	 James Liu <james@jamesliu.io>
Subject: Re: [PATCH v3 1/3] refs/reftable: introduce "reftable.lockTimeout"
Date: Thu, 19 Sep 2024 14:34:13 -0700	[thread overview]
Message-ID: <xmqqmsk35nvu.fsf@gitster.g> (raw)
In-Reply-To: <77cffd3b1eb638e05c031e2949fdc9374d599e05.1726653185.git.ps@pks.im> (Patrick Steinhardt's message of "Wed, 18 Sep 2024 11:59:27 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> +reftable.lockTimeout::
> +	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. Value 0 means not to retry at
> +	all; -1 means to try indefinitely. Default is 100 (i.e., retry for
> +	100ms).

Existing timeout knobs are in a hierarchy that is too wide
(i.e. core.*timeout) and this fixes the mistake by placing the name
in a lot more appropriate name (i.e. reftable.*timeout).  If I were
designing the system from scratch, I would probably place all of
them in "refs.*timeout", but I do not think it is worth extra
engineering effort to rename them and pay the transition cost.

> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
> index 1c4b19e737f..ca281e39a29 100644
> --- a/refs/reftable-backend.c
> +++ b/refs/reftable-backend.c
> @@ -256,6 +256,13 @@ static int reftable_be_config(const char *var, const char *value,
>  		if (factor > UINT8_MAX)
>  			die("reftable geometric factor cannot exceed %u", (unsigned)UINT8_MAX);
>  		opts->auto_compaction_factor = factor;
> +	} else if (!strcmp(var, "reftable.locktimeout")) {
> +		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;

Existing lock timeouts this models after seems to consider a
platform native "int" is good enough size to represent the timeout
value in milliseconds, but the eventual user of this value in the
lockfile API expects a long, so lock_timeout_ms being long is fine.

Perhaps #leftoverbits to straighten out the types used for the other
two timeout configuration variables.

  reply	other threads:[~2024-09-19 21:34 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 ` [PATCH v3 " Patrick Steinhardt
2024-09-18  9:59   ` [PATCH v3 1/3] refs/reftable: introduce "reftable.lockTimeout" Patrick Steinhardt
2024-09-19 21:34     ` Junio C Hamano [this message]
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=xmqqmsk35nvu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=james@jamesliu.io \
    --cc=karthik.188@gmail.com \
    --cc=ps@pks.im \
    --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.