On 2020/02/23 15:59:14, hahnjo wrote: > On 2020/02/23 15:54:54, hanwenn wrote: > > I think this is worth it because it simplifies the build system, and puts the > > locking in the place where we actually access the resource. > > Let me disagree: It complicates lilypond-book with something that no (external) > user of the script cares about. So IMHO adding brittle locking requires more > justification than that. > > > I take your point about dropped files; the best would be fcntl locks, but I am > > worried that they might not be supported on windows. Would you know? > > > > Maybe we can just use fcntl locks on unix, and Windows users should just not > try > > to run parallel lp-book invocations. > > Can we please first take a step back and see how much benefit there actually is?
To be fair, the current situation is that _anybody_ should just not try to run parallel lp-book invocations, whether from our build system, started manually from different shells with the same database, or in any other manner. The lilybook database is quite a big hack with its main purpose being speeding up our doc build. I am not quite sure whether normal lilypond-book invocations would even use it. If they do, the lock might be separately useful to what is going on in our build process. https://codereview.appspot.com/555360043/
