On Thu, Dec 17, 2009 at 8:04 PM, Graham Percival <gra...@percival-music.ca> wrote: > On Tue, Dec 15, 2009 at 10:00:20PM +0100, Matthias Kilian wrote: >> [sorry for mumbling to myself too much] >> >> On Sun, Dec 13, 2009 at 06:53:57PM +0100, Matthias Kilian wrote: >> [...] >> > - out = file (path + '.ly', 'w') >> > + out = tempfile.NamedTemporaryFile(mode = 'w', suffix = '.lytmp', >> > + dir = directory, delete = False) >> >> Unfortunately, this doesn't work with python < 2.6 (because the >> `delete' parameter is new since python-2.6). >> >> But if you gyys think that the approach of writing (and later >> renaming) temporary files may help, i'll make a better diff tomorrow. > > I think that before anybody tries to seriously solve this, we need > a reproducible bug. Something that fails 5% of the time is very > difficult to solve. :( > > Can you find some abusive combination of lilypond, lilypond-book, > make, -jX options to make, and CPU_COUNT=Y environment variables > to pass to said lilypond-book instances, that produces a reliable > bug? Getting that far is easily 80% of solving this problem.
We already have a plausible explanation, and a fairly simple solution: use flock() in ly:parse-file on the .ly file. Overwriting files is not actually a problem, since the .ly files will be overwritten by the same content. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel