[PATCH 5 of 5] lock.release: do not unlink inherited locks
Augie Fackler
raf at durin42.com
Fri Sep 25 17:37:08 UTC 2015
On Thu, Sep 24, 2015 at 04:29:40PM -0700, Siddharth Agarwal wrote:
> # HG changeset patch
> # User Siddharth Agarwal <sid0 at fb.com>
> # Date 1443135806 25200
> # Thu Sep 24 16:03:26 2015 -0700
> # Node ID 6d6573be7dc37376d9c5a22be8fbbfcdc4f2814a
> # Parent ba556998f3d950a16bd890a1d7f23ba8cdb6801c
> lock.release: do not unlink inherited locks
Queued, thanks. What's the use case?
>
> This is part of a series that will allow locks to be inherited by subprocesses
> in limited circumstances. A subprocess unlinking a lock will lead to potential
> corruption from other concurrent processes.
>
> diff --git a/mercurial/lock.py b/mercurial/lock.py
> --- a/mercurial/lock.py
> +++ b/mercurial/lock.py
> @@ -204,10 +204,11 @@ class lock(object):
> if self.releasefn:
> self.releasefn()
> finally:
> - try:
> - self.vfs.unlink(self.f)
> - except OSError:
> - pass
> + if not self._parentheld:
> + try:
> + self.vfs.unlink(self.f)
> + except OSError:
> + pass
> for callback in self.postrelease:
> callback()
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
More information about the Mercurial-devel
mailing list