Commit ab16b9a
config: retry acquiring config.lock for 100ms
When multiple processes write to a config file concurrently, they
contend on its ".lock" file, which is acquired via open(O_EXCL) with
no retry. The losers fail immediately with "could not lock config
file". Two processes writing unrelated keys (say, "branch.a.remote"
and "branch.b.remote") have no semantic conflict, yet one of them
fails for a purely mechanical reason.
This bites in practice when running `git worktree add -b` concurrently
against the same repository. Each invocation makes several writes to
".git/config" to set up branch tracking, and tooling that creates
worktrees in parallel sees intermittent failures. Worse, `git worktree
add` does not propagate the failed config write to its exit code: the
worktree is created and the command exits 0, but tracking
configuration is silently dropped.
The lock is held only for the duration of rewriting a small file, so
retrying for 100 ms papers over any realistic contention while still
failing fast if a stale lock has been left behind by a crashed
process. This mirrors what we already do for individual reference
locks (4ff0f01 (refs: retry acquiring reference locks for 100ms,
2017-08-21)).
Signed-off-by: Jörg Thalheim <joerg@thalheim.io>
Signed-off-by: Junio C Hamano <gitster@pobox.com>1 parent 2565546 commit ab16b9a
1 file changed
+12
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2903 | 2903 | | |
2904 | 2904 | | |
2905 | 2905 | | |
| 2906 | + | |
| 2907 | + | |
| 2908 | + | |
| 2909 | + | |
| 2910 | + | |
| 2911 | + | |
| 2912 | + | |
| 2913 | + | |
2906 | 2914 | | |
2907 | 2915 | | |
2908 | 2916 | | |
| |||
2986 | 2994 | | |
2987 | 2995 | | |
2988 | 2996 | | |
2989 | | - | |
| 2997 | + | |
| 2998 | + | |
2990 | 2999 | | |
2991 | 3000 | | |
2992 | 3001 | | |
| |||
3331 | 3340 | | |
3332 | 3341 | | |
3333 | 3342 | | |
3334 | | - | |
| 3343 | + | |
| 3344 | + | |
3335 | 3345 | | |
3336 | 3346 | | |
3337 | 3347 | | |
| |||
0 commit comments