# 3 messages from 2019-11-15 to 2019-11-15. Participants: Martin Nicolay, Martin Ågren. Thread: https://gitlist.dev/t/52273 ## Martin Nicolay, 2019-11-15 16:03 Subject: Message-ID: <20191115160330.A64EBD756F@wsmn.osm-gmbh.de> URL: https://gitlist.dev/e/20191115160330.A64EBD756F%40wsmn.osm-gmbh.de ``` From 7f5bb47a3b5b7a5443009078d936ab62dfa1fd85 Mon Sep 17 00:00:00 2001 From: Martin Nicolay Date: Fri, 15 Nov 2019 16:41:20 +0100 Subject: [PATCH] enable a timeout for hold_lock_file_for_update The new funktion get_files_lock_timeout_ms reads the config core.fileslocktimeout analog get_files_ref_lock_timeout_ms. This value is used in hold_lock_file_for_update instead of the fixed value 0. --- While working with complex scripts invoking git multiple times my editor detects the changes and calls "git status". This leads to aborts in "git-stash". With this patch and an appropriate value core.fileslocktimeout this problem goes away. lockfile.c | 15 +++++++++++++++ lockfile.h | 4 +++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/lockfile.c b/lockfile.c index 8e8ab4f29f..ac19de8937 100644 --- a/lockfile.c +++ b/lockfile.c @@ -145,6 +145,21 @@ static int lock_file_timeout(struct lock_file *lk, const char *path, } } +long get_files_lock_timeout_ms(void) +{ + static int configured = 0; + + /* The default timeout is 100 ms: */ + static int timeout_ms = 100; + + if (!configured) { + git_config_get_int("core.fileslocktimeout", &timeout_ms); + configured = 1; + } + + return timeout_ms; +} + void unable_to_lock_message(const char *path, int err, struct strbuf *buf) { if (err == EEXIST) { diff --git a/lockfile.h b/lockfile.h index 9843053ce8..a0520e6a7b 100644 --- a/lockfile.h +++ b/lockfile.h @@ -163,6 +163,8 @@ int hold_lock_file_for_update_timeout( struct lock_file *lk, const char *path, int flags, long timeout_ms); +long get_files_lock_timeout_ms(void); + /* * Attempt to create a lockfile for the file at `path` and return a * file descriptor for writing to it, or -1 on error. The flags @@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update( struct lock_file *lk, const char *path, int flags) { - return hold_lock_file_for_update_timeout(lk, path, flags, 0); + return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() ); } /* -- 2.13.7 ``` ## Martin Ågren, 2019-11-15 16:29 Subject: Re: Message-ID: URL: https://gitlist.dev/e/CAN0heSoW1GWEDxQN-d9bR4Vs5vzMaeDMar%3DQzShhcVNO1A0Sxg%40mail.gmail.com In-Reply-To: <20191115160330.A64EBD756F@wsmn.osm-gmbh.de> ``` Hi Martin On Fri, 15 Nov 2019 at 17:17, Martin Nicolay wrote: > While working with complex scripts invoking git multiple times my > editor detects the changes and calls "git status". This leads to > aborts in "git-stash". With this patch and an appropriate value > core.fileslocktimeout this problem goes away. Are you able to patch your editor to call git --no-optional-locks status instead? See the bottom of git-status(1) ("BACKGROUND REFRESH") for more on this. > +long get_files_lock_timeout_ms(void) > +{ > + static int configured = 0; > + > + /* The default timeout is 100 ms: */ > + static int timeout_ms = 100; > + > + if (!configured) { > + git_config_get_int("core.fileslocktimeout", &timeout_ms); > + configured = 1; > + } > + > + return timeout_ms; > +} > + > @@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update( > struct lock_file *lk, const char *path, > int flags) > { > - return hold_lock_file_for_update_timeout(lk, path, flags, 0); > + return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() ); > } This looks like it changes the default from 0 ("try exactly once") to 100ms. Maybe we should stick with 0 for those who don't jump onto this new config knob? Martin ``` ## Martin Ågren, 2019-11-15 16:37 Subject: Re: Message-ID: URL: https://gitlist.dev/e/CAN0heSprR-CMyc0qXvq5QKi4Qq5pqi%2ByvAU1%3DP%2BCp%2B%3DSg1My1g%40mail.gmail.com In-Reply-To: ``` [Trying with another e-mail address for Martin Nicolay. Maybe the one from the in-body From header works better. wsmn.osm-gmbh.de couldn't be found.] On Fri, 15 Nov 2019 at 17:29, Martin Ågren wrote: > > Hi Martin > > On Fri, 15 Nov 2019 at 17:17, Martin Nicolay wrote: > > > While working with complex scripts invoking git multiple times my > > editor detects the changes and calls "git status". This leads to > > aborts in "git-stash". With this patch and an appropriate value > > core.fileslocktimeout this problem goes away. > > Are you able to patch your editor to call > git --no-optional-locks status > instead? See the bottom of git-status(1) ("BACKGROUND REFRESH") for more > on this. > > > +long get_files_lock_timeout_ms(void) > > +{ > > + static int configured = 0; > > + > > + /* The default timeout is 100 ms: */ > > + static int timeout_ms = 100; > > + > > + if (!configured) { > > + git_config_get_int("core.fileslocktimeout", &timeout_ms); > > + configured = 1; > > + } > > + > > + return timeout_ms; > > +} > > + > > > @@ -172,7 +174,7 @@ static inline int hold_lock_file_for_update( > > struct lock_file *lk, const char *path, > > int flags) > > { > > - return hold_lock_file_for_update_timeout(lk, path, flags, 0); > > + return hold_lock_file_for_update_timeout(lk, path, flags, get_files_lock_timeout_ms() ); > > } > > This looks like it changes the default from 0 ("try exactly once") to > 100ms. Maybe we should stick with 0 for those who don't jump onto this > new config knob? > > Martin ```