From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>, Jeff King <peff@peff.net>,
git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: [PATCH 2/2] lock_packed_refs(): allow retries when acquiring the packed-refs lock
Date: Fri, 1 May 2015 16:52:57 +0200 [thread overview]
Message-ID: <1430491977-25817-3-git-send-email-mhagger@alum.mit.edu> (raw)
In-Reply-To: <1430491977-25817-1-git-send-email-mhagger@alum.mit.edu>
Currently, there is only one attempt to acquire any lockfile, and if
the lock is held by another process, the locking attempt fails
immediately.
This is not such a limitation for loose reference files. First, they
don't take long to rewrite. Second, most reference updates have a
known "old" value, so if another process is updating a reference at
the same moment that we are trying to lock it, then probably the
expected "old" value will not longer be valid, and the update will
fail anyway.
But these arguments do not hold for packed-refs:
* The packed-refs file can be large and take significant time to
rewrite.
* Many references are stored in a single packed-refs file, so it could
be that the other process was changing a different reference than
the one that we are interested in.
Therefore, it is much more likely for there to be spurious lock
conflicts in connection to the packed-refs file, resulting in
unnecessary command failures.
So, if the first attempt to lock the packed-refs file fails, continue
retrying for a configurable length of time before giving up. The
default timeout is 1 second.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Notes (discussion):
At first I wasn't going to make this setting configurable. After all,
who could object to one second?
But then I realized that making the length of the timeout configurable
would make it easier to test. Since sleep(1) is only guaranteed to
have a 1-second resolution, it is helpful to set the timeout longer
than 1 second in the test. So I made it configurable, and documented
the setting.
I don't have a strong opinion either way.
By the way, if anybody has a better idea for how to test this, please
chime up. As written, the two new tests each take about one second to
run (though they are mostly idle during that time, so they parallelize
well with other tests).
Documentation/config.txt | 6 ++++++
refs.c | 12 +++++++++++-
t/t3210-pack-refs.sh | 17 +++++++++++++++++
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2e5ceaf..3c24e10 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -622,6 +622,12 @@ core.commentChar::
If set to "auto", `git-commit` would select a character that is not
the beginning character of any line in existing commit messages.
+core.packedRefsTimeout::
+ The length of time, in milliseconds, to retry when trying to
+ lock the `packed-refs` file. Value 0 means not to retry at
+ all; -1 means to try indefinitely. Default is 1000 (i.e.,
+ retry for 1 second).
+
sequence.editor::
Text editor used by `git rebase -i` for editing the rebase instruction file.
The value is meant to be interpreted by the shell when it is used.
diff --git a/refs.c b/refs.c
index 47e4e53..3f8ac63 100644
--- a/refs.c
+++ b/refs.c
@@ -2413,9 +2413,19 @@ static int write_packed_entry_fn(struct ref_entry *entry, void *cb_data)
/* This should return a meaningful errno on failure */
int lock_packed_refs(int flags)
{
+ static int timeout_configured = 0;
+ static int timeout_value = 1000;
+
struct packed_ref_cache *packed_ref_cache;
- if (hold_lock_file_for_update(&packlock, git_path("packed-refs"), flags) < 0)
+ if (!timeout_configured) {
+ git_config_get_int("core.packedrefstimeout", &timeout_value);
+ timeout_configured = 1;
+ }
+
+ if (hold_lock_file_for_update_timeout(
+ &packlock, git_path("packed-refs"),
+ flags, timeout_value) < 0)
return -1;
/*
* Get the current packed-refs while holding the lock. If the
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index aa9eb3a..d18b726 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -187,4 +187,21 @@ test_expect_success 'notice d/f conflict with existing ref' '
test_must_fail git branch foo/bar/baz/lots/of/extra/components
'
+test_expect_success 'timeout if packed-refs.lock exists' '
+ LOCK=.git/packed-refs.lock &&
+ >$LOCK &&
+ test_when_finished "rm -f $LOCK" &&
+ test_must_fail git pack-refs --all --prune
+'
+
+test_expect_success 'retry acquiring packed-refs.lock' '
+ LOCK=.git/packed-refs.lock &&
+ >$LOCK &&
+ test_when_finished "rm -f $LOCK" &&
+ {
+ ( sleep 1 ; rm -f $LOCK ) &
+ } &&
+ git -c core.packedrefstimeout=3000 pack-refs --all --prune
+'
+
test_done
--
2.1.4
next prev parent reply other threads:[~2015-05-01 14:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 14:52 [PATCH 0/2] Retry attempts to acquire the packed-refs lock Michael Haggerty
2015-05-01 14:52 ` [PATCH 1/2] lockfile: allow file locking to be retried with a timeout Michael Haggerty
2015-05-11 18:04 ` Junio C Hamano
2015-05-01 14:52 ` Michael Haggerty [this message]
2015-05-01 16:13 ` [PATCH 2/2] lock_packed_refs(): allow retries when acquiring the packed-refs lock Johannes Sixt
2015-05-02 3:47 ` Michael Haggerty
2015-05-02 21:43 ` Johannes Sixt
2015-05-11 9:31 ` Michael Haggerty
2015-05-01 17:51 ` Stefan Beller
2015-05-01 18:22 ` Jeff King
2015-05-02 5:19 ` Michael Haggerty
2015-05-04 17:31 ` Stefan Beller
2015-05-05 19:21 ` Jeff King
2015-05-11 10:26 ` Michael Haggerty
2015-05-11 16:49 ` Jeff King
2015-05-11 17:49 ` Stefan Beller
2015-05-11 17:50 ` Stefan Beller
2015-05-03 2:12 ` [PATCH 0/2] Retry attempts to acquire " Junio C Hamano
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=1430491977-25817-3-git-send-email-mhagger@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sbeller@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).