* lockfiles & fork()
@ 2006-10-28 1:21 Johannes Schindelin
2006-10-28 1:41 ` Junio C Hamano
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Johannes Schindelin @ 2006-10-28 1:21 UTC (permalink / raw)
To: git
Hi,
when you setup a lockfile, and then fork(), you could easily end up with
atexit() kicking in to remove the lockfile, before the main process has a
chance to commit. (Yes, I need to hold the lock long before the fork()).
Any ideas how to solve the problem?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: lockfiles & fork()
2006-10-28 1:21 lockfiles & fork() Johannes Schindelin
@ 2006-10-28 1:41 ` Junio C Hamano
2006-10-28 1:52 ` Linus Torvalds
2006-10-28 13:30 ` Florian Weimer
2 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2006-10-28 1:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx•de> writes:
> when you setup a lockfile, and then fork(), you could easily end up with
> atexit() kicking in to remove the lockfile, before the main process has a
> chance to commit. (Yes, I need to hold the lock long before the fork()).
>
> Any ideas how to solve the problem?
Depends on the arrangement between the parent and child
regarding who is responsible for unlocking. If child expects to
work under the safety of the lock the parent prepared, and also
relies on the parent to wait for it and then unlock to ensure
that safety for the child, then I think the problem is simple.
How about defining a function in lockfile.c to assign NULL to
lock_file_list and call that immediately after fork() in the
child?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lockfiles & fork()
2006-10-28 1:21 lockfiles & fork() Johannes Schindelin
2006-10-28 1:41 ` Junio C Hamano
@ 2006-10-28 1:52 ` Linus Torvalds
2006-10-28 13:30 ` Florian Weimer
2 siblings, 0 replies; 4+ messages in thread
From: Linus Torvalds @ 2006-10-28 1:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On Sat, 28 Oct 2006, Johannes Schindelin wrote:
>
> when you setup a lockfile, and then fork(), you could easily end up with
> atexit() kicking in to remove the lockfile, before the main process has a
> chance to commit. (Yes, I need to hold the lock long before the fork()).
The easiest way to handle this would be for the lockfile logic to just
save the pid associated with each lockfile... And for the atexit function
to just ignore it if the pid doesn't match.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lockfiles & fork()
2006-10-28 1:21 lockfiles & fork() Johannes Schindelin
2006-10-28 1:41 ` Junio C Hamano
2006-10-28 1:52 ` Linus Torvalds
@ 2006-10-28 13:30 ` Florian Weimer
2 siblings, 0 replies; 4+ messages in thread
From: Florian Weimer @ 2006-10-28 13:30 UTC (permalink / raw)
To: git
* Johannes Schindelin:
> when you setup a lockfile, and then fork(), you could easily end up with
> atexit() kicking in to remove the lockfile, before the main process has a
> chance to commit. (Yes, I need to hold the lock long before the fork()).
>
> Any ideas how to solve the problem?
I think you should call _exit in the child instead of exit.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-10-28 13:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-28 1:21 lockfiles & fork() Johannes Schindelin
2006-10-28 1:41 ` Junio C Hamano
2006-10-28 1:52 ` Linus Torvalds
2006-10-28 13:30 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox