lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by addr


From: jonas . hahnfeld
Subject: Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by address@hidden)
Date: Wed, 26 Feb 2020 00:28:33 -0800

On 2020/02/26 08:19:39, hahnjo wrote:
> 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.

That said: I'm also fine if some other developer accepts this patch. See
my timing data above to get to your own conclusion. After all, my
opinion is just one of a larger range.

https://codereview.appspot.com/555360043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]