Concurrent builds of the same configuration race in one build directory and both fail #839

Summary

Two mcpp build processes on the same project and the same configuration run two ninja instances in the same build directory (target/<triple>/<fingerprint>/). On a cold build they delete and overwrite each other's BMIs, and both fail.

This is the ordinary situation of an IDE building on save while a person (or a coding agent) runs mcpp build / mcpp run in a terminal.

Reproduction (mcpp 2026.10.24.1, gcc@16.1.0, Linux x86_64)

d=/tmp/lockexp; rm -rf $d; mkdir -p $d/src; cd $d
printf '[package]\nname = "lk"\nversion = "0.1.0"\nstandard = "c++23"\n[toolchain]\ndefault = "gcc@16.1.0"\n' > mcpp.toml
for i in $(seq 1 24); do printf 'export module m%d;\nimport std;\nexport int f%d(){ std::vector<int> v(%d); return (int)v.size(); }\n' $i $i $i > src/m$i.cppm; done
{ echo 'import std;'; for i in $(seq 1 24); do echo "import m$i;"; done; echo 'int main(){ std::println("{}", f1()+f24()); }'; } > src/main.cpp

for r in 1 2 3 4 5; do
  rm -rf target
  ( mcpp build >/tmp/r1.log 2>&1; echo $? >/tmp/r1.rc ) &
  ( sleep 0.$r; mcpp build >/tmp/r2.log 2>&1; echo $? >/tmp/r2.rc ) &
  wait; echo "round $r: rc=$(cat /tmp/r1.rc),$(cat /tmp/r2.rc)"
done

Observed

3 of 5 rounds: both processes exit 1, with errors such as

/tmp/lockexp/src/m6.cppm:1:8: error: failed to write compiled module: No such file or directory
m5: error: failed to read compiled module: No such file or directory

In the 2 rounds that pass, both processes compiled everything (the work is done twice). A following mcpp build recovers.

Not affected (measured)

• Different configurations in parallel (mcpp build + mcpp build --release): different fingerprint directories, both succeed.
• Rebuilding while a previously built program is still running under mcpp run: succeeds on Linux; the running process keeps the old file.
• Read-only queries during a build (mcpp emit build-database --format json): succeed.

The global side already guards its shared state (index refresh: non-blocking file lock; BMI cache: per-entry lock + staged publish; toolchain install: per-version directory). The project build directory is the one shared mutable resource with no cross-process guard.

The fix is being designed together with related contract work (build pipeline split into plan / mutate / execute, lock held only for the mutate phase, per build directory); this issue records the defect and its reproduction.