summaryrefslogtreecommitdiff
path: root/setup.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2018-03-30 19:26:15 (GMT)
committerJunio C Hamano <gitster@pobox.com>2018-03-30 19:52:46 (GMT)
commit05e293c1ac63295fcfe1b8fd9533fcdb012d5f03 (patch)
treea5a3f5d96b8f644f0fefc32b0e2c2c71e8aaed97 /setup.c
parent3013dff8662eae06457fe6e5348dfe2270810ab2 (diff)
downloadgit-05e293c1ac63295fcfe1b8fd9533fcdb012d5f03.zip
git-05e293c1ac63295fcfe1b8fd9533fcdb012d5f03.tar.gz
git-05e293c1ac63295fcfe1b8fd9533fcdb012d5f03.tar.bz2
config: move flockfile() closer to unlocked functions
Commit 260d408e32 (config: use getc_unlocked when reading from file, 2015-04-16) taught git_config_from_file() to lock the filehandle so that we could safely use the faster unlocked functions to access the handle. However, it split the logic into two places: 1. The master lock/unlock happens in git_config_from_file(). 2. The decision to use the unlocked functions happens in do_config_from_file(). That means that if anybody calls the latter function, they will accidentally use the unlocked functions without holding the lock. And indeed, git_config_from_stdin() does so. In practice, this hasn't been a problem since this code isn't generally multi-threaded (and even if some Git program happened to have another thread running, it's unlikely to be reading from stdin). But it's a good practice to make sure we're always holding the lock before using the unlocked functions. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'setup.c')
0 files changed, 0 insertions, 0 deletions