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.

[redactedontop]

Any updates?

[ConradIrwin]

One important aspect of this (for me at least) is prioritizing user requests over background requests (for example from LSPs). Building Zed consumes all my CPU cores, and I'd like the rust-analyzer diagnostics to get out of my way when I run cargo run.

[epage]

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.

For GC, Cargo has extended its file lock mechanism with effectively the semantics of (Read OR Append) XOR Write. A potential workaround would be to lock the entire build directory for Append (hand waiving away crates that need to be modified).

Another potential level to this problem is that we grab a Read lock for the workspace build directory and write only to a process build directory. Once we are done, we then move over any parts of the process build directory that weren't already in the workspace build directory. Risks include (1) race conditions (2) builds would happen in parallel, rather than serialized, potentially making the machine grind to a halt (currently --jobs effectively governs the workspace, not just the current process)