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

[jonas . hahnfeld]

On 2020/02/26 07:59:36, hanwenn wrote:
> On Tue, Feb 25, 2020 at 11:09 PM <mailto:address@hidden>
wrote:
> > Another solution might be serialize only lilypond-book and let tex
et
> > al. run concurrently. That should also be harmless, right?
> 
> But this is exactly what this patch does.

I meant "serialize only lilypond-book in the Makefile [...]", sorry for
not being specific. I agree that this patch attempts to go this way in
lilypond-book, and that's what I object to, see below.

> I don't understand your objection. Serializing mechanism in the
> makefile are obscure and hard to understand, because build systems
> want to do as many things in parallel as possible.

... so it's the build system's responsibility to get things right. In
our case this means: Do *not* call lilypond-book in parallel.

> 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
complexity if it only helps for a single case in our build (ie
input/regression/lilypond-book/).

> 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/