{"thread":{"id":"43180","subject":"lockfiles & fork()","startedAt":"2006-10-28T01:21:38Z","lastAt":"2006-10-28T13:30:27Z","messageCount":4,"participants":["Johannes Schindelin","Junio C Hamano","Linus Torvalds","Florian Weimer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293981","messageId":"Pine.LNX.4.63.0610280319250.26682@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43180","inReplyTo":null,"subject":"lockfiles & fork()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-28T01:21:38Z","receivedAt":"2006-10-28T01:21:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nwhen you setup a lockfile, and then fork(), you could easily end up with \natexit() kicking in to remove the lockfile, before the main process has a \nchance to commit. (Yes, I need to hold the lock long before the fork()).\n\nAny ideas how to solve the problem?\n\nCiao,\nDscho\n"},{"id":"294497","messageId":"7v64e5cj39.fsf@assigned-by-dhcp.cox.net","threadId":"43180","inReplyTo":"Pine.LNX.4.63.0610280319250.26682@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: lockfiles & fork()","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-28T01:41:46Z","receivedAt":"2006-10-28T01:41:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> when you setup a lockfile, and then fork(), you could easily end up with \n> atexit() kicking in to remove the lockfile, before the main process has a \n> chance to commit. (Yes, I need to hold the lock long before the fork()).\n>\n> Any ideas how to solve the problem?\n\nDepends on the arrangement between the parent and child\nregarding who is responsible for unlocking.  If child expects to\nwork under the safety of the lock the parent prepared, and also\nrelies on the parent to wait for it and then unlock to ensure\nthat safety for the child, then I think the problem is simple.\n\nHow about defining a function in lockfile.c to assign NULL to\nlock_file_list and call that immediately after fork() in the\nchild?\n"},{"id":"298287","messageId":"Pine.LNX.4.64.0610271851130.3849@g5.osdl.org","threadId":"43180","inReplyTo":"Pine.LNX.4.63.0610280319250.26682@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: lockfiles & fork()","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-28T01:52:19Z","receivedAt":"2006-10-28T01:52:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 28 Oct 2006, Johannes Schindelin wrote:\n> \n> when you setup a lockfile, and then fork(), you could easily end up with \n> atexit() kicking in to remove the lockfile, before the main process has a \n> chance to commit. (Yes, I need to hold the lock long before the fork()).\n\nThe easiest way to handle this would be for the lockfile logic to just \nsave the pid associated with each lockfile... And for the atexit function \nto just ignore it if the pid doesn't match. \n\n"},{"id":"298445","messageId":"87fyd8ftzg.fsf@mid.deneb.enyo.de","threadId":"43180","inReplyTo":"Pine.LNX.4.63.0610280319250.26682@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: lockfiles & fork()","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2006-10-28T13:30:27Z","receivedAt":"2006-10-28T13:30:27Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Johannes Schindelin:\n\n> when you setup a lockfile, and then fork(), you could easily end up with \n> atexit() kicking in to remove the lockfile, before the main process has a \n> chance to commit. (Yes, I need to hold the lock long before the fork()).\n>\n> Any ideas how to solve the problem?\n\nI think you should call _exit in the child instead of exit.\n"}]}