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/