threads / discuss / 43180

lockfiles & fork()

Subject: lockfiles & fork()

## tl;dr

4 messages between Oct 28, 2006 and Oct 28, 2006.

replies: 3people: 4as markdown or json

Johannes Schindelin· Oct 28, 2006, 01:21 UTC · lore

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

Junio C Hamano· Oct 28, 2006, 01:41 UTC · re: Johannes Schindelin · lore

Re: lockfiles & fork()

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> 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?

Linus Torvalds· Oct 28, 2006, 01:52 UTC · re: Johannes Schindelin · lore

Re: lockfiles & fork()

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.

Florian Weimer· Oct 28, 2006, 13:30 UTC · re: Johannes Schindelin · lore

Re: lockfiles & fork()

* Johannes Schindelin:

Show 5 quoted lines

> 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.