summaryrefslogtreecommitdiff
path: root/lockfile.c
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2007-04-21 03:11:10 -0700
committerJunio C Hamano <junkio@cox.net>2007-04-21 11:55:23 -0700
commit5e635e396020cc08bc21a3e67c20c5294d6d13fd (patch)
treed11c19f13482c6b92de47ee80e79ebd28f1b6e13 /lockfile.c
parent6073ee85719be6d959e74aa667024fcbec44a588 (diff)
downloadgit-5e635e396020cc08bc21a3e67c20c5294d6d13fd.tar.gz
lockfile: record the primary process.
The usual process flow is the main process opens and holds the lock to the index, does its thing, perhaps spawning children during the course, and then writes the resulting index out by releaseing the lock. However, the lockfile interface uses atexit(3) to clean it up, without regard to who actually created the lock. This typically leads to a confusing behaviour of lock being released too early when the child exits, and then the parent process when it calls commit_lockfile() finds that it cannot unlock it. This fixes the problem by recording who created and holds the lock, and upon atexit(3) handler, child simply ignores the lockfile the parent created. Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'lockfile.c')
-rw-r--r--lockfile.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/lockfile.c b/lockfile.c
index bed6b21daf..23db35aff2 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -8,8 +8,11 @@ static const char *alternate_index_output;
static void remove_lock_file(void)
{
+ pid_t me = getpid();
+
while (lock_file_list) {
- if (lock_file_list->filename[0])
+ if (lock_file_list->owner == me &&
+ lock_file_list->filename[0])
unlink(lock_file_list->filename);
lock_file_list = lock_file_list->next;
}
@@ -28,6 +31,7 @@ static int lock_file(struct lock_file *lk, const char *path)
sprintf(lk->filename, "%s.lock", path);
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
+ lk->owner = getpid();
if (!lk->on_list) {
lk->next = lock_file_list;
lock_file_list = lk;