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

[Han-Wen Nienhuys]

On Sun, Dec 13, 2009 at 12:44 PM, David Kastrup <address@hidden> wrote:

>>> Be warned that sometimes lilypond-book has hash collisions in the
>>> filename, which can lead to weird compile errors when one process
>>> finished dealing with aa/lily-aaaa.ps (and thus deletes it), while
>>> another process has finished generating aa/lily-aaaa.ps but hasn't
>>> started running ps2pdf yet, and thus doesn't find the file that it
>>> just wrote.
>>
>> Do you have real evidence for that?  We use 10 hex digits, yielding
>> 2^40 combinations, so a 2^20 (one in a million) chance of collisions.
>
> If we are talking about 2 particular files colliding.  If we are talking
> about a collision in n files, there are n(n+1)/2 combinations all of
> which have a 2^20 chance of collision (of course, those are not
> independent collisions, but the approximation is pretty good).  A 1%
> chance of collision is (first order approximation) achieved when
> n(n+1)/2=10000, meaning n is something like 140.
>
> Close enough to make 40 bits feel uncomfortable.

This is trivially fixed by changing the line

            ## let's not create too long names.
            self.checksum = hash.hexdigest ()[:10]

in lilypond-book.py, I doubt that this will fix the problem though.

Note that the proposed race condition would also require the colliding
files to be processed by different lilypond subprocesses, and be
passing through the (ps -> pdf) conversion of the same file at the
same time.

theoretically, not impossible but I would not bet my money on this
being the problem.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen