Change:
Since I started using vscode, it is now often the case that the which vscode runs is still not done when I alt-tab back to my terminal to do (for example) . That regularly leads to errors like this: In those cases, just running again solves the problem -- but it would still be better if having vscode run in background would not break what I do in the terminal. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So there's several solutions to this: Don't support this, tell people to run x.py check in a different directory so the build directory goes elsewhere. Add a global lock like Cargo's on the build directory Specialize x.py check to use different sysroot for stage0 - i.e. don't fix x.py build and test running simultaneously etc I am interested in hearing which you think would be preferable. Cc
If they could run truly in parallel that would be great. However, a separate build dir also means the bootstrap rustc is downloaded again, right? That would not be great.
Yes, option 1 would duplicate the stage0 rustc downloads. Option 3, though, would not - it's probably the right choice I think since x.py check is somewhat unique in being the most likely to be invoked in parallel.
in an ideal world, would fixing also fix this?
Not really. It might even make things worse. rustbuild uses the same stamps for both check and build steps (and sysroots etc) so when both are running simultaneously we will stomp all over the other, which is going to lead to incorrect behavior.
I was not able to replicate this. On my machine running both in parallel gives
Ok, I figured out when this happens: you need one terminal to be building the compiler while the other is building libstd. If both are building libstd this error doesn't show up.
I think this can also lead to losing the build cache... at least I just had a case where after showing this error, it then (on the next attempt) proceeded to rebuild the crate graph rustc depends on, instead of just the crate that I changed.
FYI option 3 was seen as too big a hammer in ; the proposed fix was to use a build lock on the sysroot instead, the same way cargo has a build lock for .
I think that's not quite accurate, in the specialization was too specific (i.e., the problem is more widespread, any two x.py runs can touch shared files currently). "Insufficiently big hammer" is probably the right description of option 3.
claim
I am afraid this is still not working properly: when I run in the terminal while there is a vscode running in the background, I get but once vscode is done, all that happens is that the in the terminal starts using 100% CPU. It does not actually start running though.
Ah: looks like it missed actually breaking out of that loop -- happy to accept a PR to do so.
is that something you could take a look at?

Discussion:
import tarfile import tempfile <del> from time import time </del> <ins> from time import time, sleep </ins> # Acquire a lock on the build directory to make sure that # we don't cause a race condition while building

while True: try: curs.execute("BEGIN EXCLUSIVE") <ins> break </ins> except sqlite3.OperationalError: pass <ins> sleep(0.25) </ins> return curs except ImportError: print("warning: sqlite3 not available in python, skipping build directory lock")