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

[dak]

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.

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