lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `make check' overworks one core on my Core2 quad


From: John Mandereau
Subject: Re: `make check' overworks one core on my Core2 quad
Date: Sun, 13 Dec 2009 21:13:10 +0100

Hi Han-Wen,
Le dimanche 13 décembre 2009 à 13:55 -0200, Han-Wen Nienhuys a écrit :
> Oh wait - there is one thing I did not think about: snippets may be
> shared by different documents, so if you use make -jX it is
> conceivable that make invokes two separate lilypond processes that
> have non-empty intersection of their arguments.

I don't understand this.  I made sure that no simultaneous lilypond-book
instances can run simultaneously (unless you make run several instances
of 'make doc' simultaneously in the same build tree) a bit more than one
year ago, and AFAICT this still works.  If it doesn't in any case, I
expect a report.


> For now, the easy fix is to use -j1 with CPU_COUNT for building the docs.

If the make trick I mentioned above works, then the problem is not with
-j make flag but with CPU_COUNT greater than one, which tells
lilypond-book to run as many lilypond instances (I'm sure you know this,
this is only to make it clear).


> A more elaborate solution would be either some kind of locking, or to
> check whether the .ps / .pdf exists before actually processing the
> .ly; the latter is still suscepitible to races, though, but a check
> could make the opportunity window smaller.

I hope we can figure out a simpler solution, like lengthening the
hashes, and/or even better really avoiding processing the same snippet
twice (if it ever happens).


> A last solution would be to unshare the snippet database, but that
> would mean a lot of double processing and extra disk usage, because
> every translation would have to do 90% of the snippets all over again,
> and store them separately.

Gosh, our docs are already generous enough with disk usage :-)

Best,
John

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


reply via email to

[Prev in Thread] Current Thread [Next in Thread]