[PATCH V2] lock: while releasing, unlink lockfile even if the release function throws
pierre-yves.david at ens-lyon.org
Fri Oct 17 16:35:31 CDT 2014
On 10/17/2014 09:49 AM, Siddharth Agarwal wrote:
> # HG changeset patch
> # User Siddharth Agarwal <sid0 at fb.com>
> # Date 1413512151 25200
> # Thu Oct 16 19:15:51 2014 -0700
> # Node ID 5d07ba572ebef1d409e7dcc75f469248447cba7b
> # Parent 840be5ca03e1db16ba994e55597771c418166c97
> lock: while releasing, unlink lockfile even if the release function throws
> Consider a hypothetical bug in the release function that causes it to raise an
> exception. Also consider the bisect command, which saves its state in a finally
> clause. Saving the state requires acquiring the wlock.
> If we don't unlink the lockfile when the exception is thrown, we'll try to
> acquire the wlock again. We're going to try and acquire a lock again while our
> old lockfile is on disk. The PID on disk is our own, and of course we're still
> running, so we won't take over the lock. Hence we'll be stuck waiting for a
> lock that we left behind ourselves.
> To avoid this, always unlink the lockfile. This preserves the invariant that
> self.held > 0 is equivalent to the lockfile existing on disk.
This version looks fine to me and have been pushed to the clowncopter.
More information about the Mercurial-devel