diff options
author | Michael Haggerty <mhagger@alum.mit.edu> | 2014-10-01 12:28:28 +0200 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-10-01 13:49:00 -0700 |
commit | 2091c5062c6fd928e1ad3e7c059243e597cb8bbf (patch) | |
tree | b7295f2f451ba03831fcd2e44f2ac80f7a5a20fc /lockfile.c | |
parent | 707103fdfd0c03511fa547d9b80638d8160f1a88 (diff) | |
download | git-2091c5062c6fd928e1ad3e7c059243e597cb8bbf.tar.gz |
struct lock_file: declare some fields volatile
The function remove_lock_file_on_signal() is used as a signal handler.
It is not realistic to make the signal handler conform strictly to the
C standard, which is very restrictive about what a signal handler is
allowed to do. But let's increase the likelihood that it will work:
The lock_file_list global variable and several fields from struct
lock_file are used by the signal handler. Declare those values
"volatile" to (1) force the main process to write the values to RAM
promptly, and (2) prevent updates to these fields from being reordered
in a way that leaves an opportunity for a jump to the signal handler
while the object is in an inconsistent state.
We don't mark the filename field volatile because that would prevent
the use of strcpy(), and it is anyway unlikely that a compiler
re-orders a strcpy() call across other expressions. So in practice it
should be possible to get away without "volatile" in the "filename"
case.
Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'lockfile.c')
-rw-r--r-- | lockfile.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/lockfile.c b/lockfile.c index d35ac448f0..89043f5acc 100644 --- a/lockfile.c +++ b/lockfile.c @@ -55,7 +55,7 @@ * on_list is set. */ -static struct lock_file *lock_file_list; +static struct lock_file *volatile lock_file_list; static void remove_lock_file(void) { |