[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