git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: lockfiles & fork()

From
Junio C Hamano <junkio@cox.net>
Date
Oct 28, 2006, 01:41 UTC
Message-ID
<7v64e5cj39.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.63.0610280319250.26682@wbgn013.biozentrum.uni-wuerzburg.de>
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?

Previous: Johannes SchindelinNext: Linus Torvalds
Message 2 of 4 in “lockfiles & fork()”
  1. Johannes SchindelinOct 28, 2006
  2. Junio C HamanoOct 28, 2006
  3. Linus TorvaldsOct 28, 2006
  4. Florian WeimerOct 28, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.