Concurrent usage of cargo will generally result in badness

[alexcrichton]

Cargo does a number of unsynchronized and racy operations that lead to lots of badness if they happen concurrently. This includes, but is not limited to, management of target/, checkouts into ~/.cargo/git/, and anything having to do with concurrent compilations.

The only real reasonable solution I can think of to this is the same as the "big hammer" solution which is to just "add a lock to everything". Ideally we would separately lock ~/.cargo and the local directory, but they should both in general be locked when performing any action.

[wycats]

Rust, Y U NO flock implementation 😉

[metajack]

Note that rustpkg had the same problem and so does pretty much every other build tool I've tested that keeps state around. Most people just punt on this it seems.

This really only causes problems when you are trying to usecargo inside of another build system which parallelizes things (like make -j).

[alexcrichton]

Hm yes, after looking into semaphores and file locks, I'm tempted to punt on this for now until (and if) it becomes pressing again.

[metajack]

It occurs to me if you did want to go down this route that something like SQLite may have already solved the main issues, and you could just store state in that.