More granular locking in cargo_rustc

[alexcrichton]

Right now whenever a build happens we lock the entirety of the target directory for the whole build, but it may be possible for us to have a more granular locking strategy which allows multiple instances of Cargo to proceed in parallel instead of serializing them.

[alexcrichton]

cc https://bugzilla.mozilla.org/show_bug.cgi?id=1380321

[epage]

As part of #5931, we've talked about changing the target directory layout so that there is a directory per package. This would give us more definitive units to lock.

[epage]

In #5931, we discuss having a directory per intermediate artifact inside of a user-wide cache directory. Each intermediate artifact would be lockable so there is exclusive access on the initial write and then multiple readers after that that prevent during builds. Depending on packages out of this shared location is important so we don't waste time copying things out.

To keep things simple, ideally we model the target directory the same way. So in a way, fixing this issue is a perfect subset of #5931.

We'd need a separate lock for the artifact directory though cargo check and cargo clippy shouldn't need that.

Any compilation that changes the fingerprint but not the -Cextra-filename would need to have exclusive access to the directory.

Therefore, the benefit of this feature would be limited to one of

• check orclippy together or with a single full build command (build, run, test, doc)
• Different enough --features
• Different enough --packages
• Different compilation modes (check, rustdoc, build)
  • clippy is not a separate mode but I think we do track it as separate somehow ("rustc"?)
• Different RUSTFLAGS if fix(fingerprint): Don't throwaway the cache on RUSTFLAGS changes  #14830 is merged
• Different profile

[ehuss]

I think it would be good to also keep on eye on performance, since this could introduce more OS overhead. I'm also uncertain if we will run into lock limits, particularly on networked filesystems or filesystems like Docker, etc. It looks like the number of locks is configurable in Linux, but I don't immediately see any strict limits anywhere else.