Chaos ensues when cargo miri is run concurrently

[RalfJung]

Two instances of cargo miri running concurrently can lead to the following fun situation:

• A creates and fills the Xargo.toml.
• B empties the Xargo toml.
• A runs xargo.
• (B fills the Xargo.toml but now it's too late.)

Then we end up building a no-std systroot. oops
We need to either do the Xargo.toml writing atomically via rename or so and hope that xargo itself is fine with the concurrency, or (probably better) have some kind of file system locking.

Thanks to @matthiaskrgr for reporting this.

[RalfJung]

• Cargo has its own file locking in this file.
• xargo seems to have a copy of it here.

So I guess we could just have another copy in Miri to resolve this? 😂

Maybe going with an atomic rename is the better strategy after all...

[RalfJung]

Uh, no, I have specifically edited the comment to not indicate that this should be closed...

[RalfJung]

@matthiaskrgr the latest nightly has a Miri with this fix. Could you give that a try?

[matthiaskrgr]

running miri in parallel since two hours now and i did not run into problems yet :)

[RalfJung]

Awesome. :) Going to close this as fixed then.