Likely race conditions when core library files are modified

[cristianoc]

See for example #5539 (comment)

Commands behaving non-deterministically, i.e. run it again and you might get a different result:
1 ./scripts/ninja.js clean, config , build
2 node scripts/install -force-lib-rebuild

It could be that running with ninja -j 1 makes this more deterministic. If so that would confirm.

[cristianoc]

CC @cknitt

[cristianoc]

On the linked pr, command 2 seems to be wrong approximately half of the times

[cristianoc]

I have run node scripts/install -force-lib-rebuild 10 times on #5539 with -j 1 and not once has it given a wrong result.

[cristianoc]

Another observation is that clean / config / build would sometime produce garbled js files with the closing } appearing twice.

[cristianoc]

Also every single time: doing build a second time runs about 700 steps again. The third time it does nothing.

[cknitt]

The problem seems to be that there are two copies of the Js module, and you only modified one of them in #5539.

The duplicate Js module was introduced here: 148d57f

[cristianoc]

The duplicate Js module was introduced here: 148d57f

Looks like it might have been only introduced to hide certain types used by the compiler and not exposed to the user.

[cristianoc]

Still, there are race conditions. This file duplication is simply something that makes the race conditions obvious.

[cristianoc]

CC @TheSpyder

[TheSpyder]

Turns out my problem wasn't race conditions, rather actual compile errors caused by changes on the master branch. Sorry for jumping to conclusions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.