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

[dak]

On 2020/02/28 18:14:14, dak wrote:
> On 2020/02/28 17:57:06, hanwenn wrote:
> > On 2020/02/26 11:59:14, dak wrote:
> 
> > > It doesn't state at all what happens in cases of contentions. 
Fixing
> > > contentions with a lock is a brute-force solution just not
allowing for
> > > parallelism, but it is a solution to the contention problem.
> > > 
> > > It is not a solution to lilypond-book starting more jobs than Make
knows
> about. 
> > > Or to all but one lilypond-book invocation not doing any progress
and
> blocking
> > > Make which could instead start other actual single-process tasks. 
So I see
> this
> > > patch and its approach as an improvement to lilypond-book.  I
don't see that
> it
> > > solves the parallel build carnage: it just scales down the impact
from
> having to
> > > choose between complete serialization and database failure.
> > 
> > David, I think you are saying this patch is LGTM - could you be
explicit, so
> > james understands what is going on?
> 
> I think this patch is an improvement over the status quo.  It's sort
of a crutch
> that works only on some systems and not on NFS as far as I understand.
 And it
> doesn't actually work well as a job control measure in connection with
parallel
> Make.  But it does improve lilypond-book behavior on some systems.  I
think that
> a restricted form of locking is better than nothing.  I am
incidentally not sure
> just what kind of file systems minimal VMs without a file system of
their own
> work with: if they get an NFS view, this would not even work with
Lilydev which
> would be bad.  But I don't know how VMs do file systems without a
partition of
> their own.

Sigh.  I just noticed that opposed to the patch title, this does not
just introduce a file lock for lilypond-book but _also_ changes the
build system such that now almost double the number of allocated jobs
get used.  It would be good if different topics weren't conflated into
single issues so that it's easier to discuss what one is actually
dealing with and make decisions based on the respective merits of the
individual parts.

"It doesn't actually work well as a job control measure in connection
with parallel Make" should likely have been an indicator of what I
thought I was talking about.

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