Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by address@hidden)

[Han-Wen Nienhuys]

On Wed, Feb 26, 2020 at 9:19 AM <address@hidden> wrote:
> > A lock (a file lock, in this case) is the standard solution for
> > serializing concurrent access to a shared resource (a standard
> > problem). What is your objection against using a standard solution?
>
> Yes, locks are a standard solution, but file locks are brittle. I've
> seen them fail far too often (ever had your apt-get / yum / pacman error
> out because there was a lock-file?) so I object to adding this

No, not of late.

it's useful to distinguish between "file locks" and "lock files".  The
latter are a form of the former, but they rely on the lock process to
remove lock files if the process aborts.

Git uses these files pervasively, the reason being that this is the
only way to make locking work on NFS. Maybe you've seen problems with
Git?

fcntl locks used here are managed by the kernel. If the process
holding the lock dies, the lock is freed. So there is no staleness
(but they don't work on NFS). I challenge you to come up with a
mechanism where one can observe brittle behavior.

In this patch, we create a "xxx.lock" file, which is a little ugly.
Let me see if we can lock the directory directly.

>
> > On a philosophical level, it is a lilypond-book implementation detail
> > that it can't deal with concurrent invocation, so the remediation for
> > this problem should be in lilypond-book too.
>
> Let me disagree: It's an implementation detail of make that it runs
> things in parallel. IMHO a build system should ensure that the result of
> running with multiple jobs is the same as a sequential run.
>
> https://codereview.appspot.com/555360043/



-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen