summaryrefslogtreecommitdiff
path: root/lockfile.c
diff options
context:
space:
mode:
authorMichael Haggerty <mhagger@alum.mit.edu>2014-10-01 12:28:42 +0200
committerJunio C Hamano <gitster@pobox.com>2014-10-01 13:56:14 -0700
commit697cc8efd944a32ca472337cd6640004c474b788 (patch)
treea8999149e7e907e2b65b6617bd5d45d6c675a72e /lockfile.c
parent216aab1e3d8eef088dc9785febce24a110e9f835 (diff)
downloadgit-697cc8efd944a32ca472337cd6640004c474b788.tar.gz
lockfile.h: extract new header file for the functions in lockfile.cmh/lockfile
Move the interface declaration for the functions in lockfile.c from cache.h to a new file, lockfile.h. Add #includes where necessary (and remove some redundant includes of cache.h by files that already include builtin.h). Move the documentation of the lock_file state diagram from lockfile.c to the new header file. 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.c52
1 files changed, 1 insertions, 51 deletions
diff --git a/lockfile.c b/lockfile.c
index 63f4e94bce..d27e61cafc 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -2,59 +2,9 @@
* Copyright (c) 2005, Junio C Hamano
*/
#include "cache.h"
+#include "lockfile.h"
#include "sigchain.h"
-/*
- * File write-locks as used by Git.
- *
- * For an overview of how to use the lockfile API, please see
- *
- * Documentation/technical/api-lockfile.txt
- *
- * This module keeps track of all locked files in lock_file_list for
- * use at cleanup. This list and the lock_file objects that comprise
- * it must be kept in self-consistent states at all time, because the
- * program can be interrupted any time by a signal, in which case the
- * signal handler will walk through the list attempting to clean up
- * any open lock files.
- *
- * A lockfile is owned by the process that created it. The lock_file
- * object has an "owner" field that records its owner. This field is
- * used to prevent a forked process from closing a lockfile created by
- * its parent.
- *
- * The possible states of a lock_file object are as follows:
- *
- * - Uninitialized. In this state the object's on_list field must be
- * zero but the rest of its contents need not be initialized. As
- * soon as the object is used in any way, it is irrevocably
- * registered in the lock_file_list, and on_list is set.
- *
- * - Locked, lockfile open (after hold_lock_file_for_update(),
- * hold_lock_file_for_append(), or reopen_lock_file()). In this
- * state:
- * - the lockfile exists
- * - active is set
- * - filename holds the filename of the lockfile
- * - fd holds a file descriptor open for writing to the lockfile
- * - owner holds the PID of the process that locked the file
- *
- * - Locked, lockfile closed (after successful close_lock_file()).
- * Same as the previous state, except that the lockfile is closed
- * and fd is -1.
- *
- * - Unlocked (after commit_lock_file(), commit_lock_file_to(),
- * rollback_lock_file(), a failed attempt to lock, or a failed
- * close_lock_file()). In this state:
- * - active is unset
- * - filename is empty (usually, though there are transitory
- * states in which this condition doesn't hold). Client code should
- * *not* rely on the filename being empty in this state.
- * - fd is -1
- * - the object is left registered in the lock_file_list, and
- * on_list is set.
- */
-
static struct lock_file *volatile lock_file_list;
static void remove_lock_files(void)