On 2020/02/23 16:05:08, dak 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. > > Is there any indication that letting Make run multiple instances of > lilypond-book with every instance except one at a time locking up is going to be > a net win for performance?
input/regression/lilypond-book: rm -rf out-tst; time make out=tst local-test -j4 CPU_COUNT=4 before real 1m16.588s after real 0m25.224s > I still don't see what this is supposed to buy us over using CPU_COUNTS for > invoking parallel LilyPond instances. In particular since the parallel LilyPond > instances are forked off at a time when LilyPond has completed its startup, and > in the context of the current Guile-v2 integration, startup times are relevant. > Even though considering the number of files processed in one LilyPond process, > their overall impact should still be comparatively confined. The problem is that several other things are serialized in the build because of lilypond-book. I used fcntl locking which impervious to stale locks (exiting a process drops locks automatically) https://codereview.appspot.com/555360043/