RUST_TEST_THREADS=1 no longer uses a single thread in cargo test

[uazu]

Problem

In 1.66.1 and previous, RUST_TEST_THREADS=1 (or --test-threads=1) used a single thread to run the tests. After that point the behaviour changed. Cargo now apparently uses multiple threads but with a lock to ensure that only one thread runs at a time. This change of behaviour has broken some of my tests for https://crates.io/crates/stakker.

Stakker can run multi-threaded, but as a single-threaded optimisation I allow a single thread to effectively become "special". If Stakker is started on that thread, then it can safely use global variables internally as an optimisation. However if Stakker is then started on any other thread, it panics. This is fine when the app is structured as a main thread plus auxiliary threads. However, with the new behaviour my single-threaded tests are panicking.

This is a valid use-case. The code is sound. It would be preferable to use cargo test to test it and not to have to resort to any other kind of tooling.

Whilst I can continue to run the other tests fine (cargo test runs the multi-threaded tests by default), I do need to also test the single-threaded functionality. So I will have to improvise something for now. I'll see if I can use --list and run them one by one. But it would be helpful if the --test-threads=1 option went back to doing as the name suggests.

Steps

• Checkout Stakker on Linux (or something with a bash shell)
• Execute ./run-test-all which executes all tests, including single-threaded ones

On 1.68.1, you will see lots of assertion failures due to the thread-id being different to expected.

Possible Solution(s)

Revert whatever change introduced this?

Notes

No response

Version

cargo 1.68.1 (115f34552 2023-02-26)
release: 1.68.1
commit-hash: 115f34552518a2f9b96d740192addbac1271e7e6
commit-date: 2023-02-26
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Arch Linux [64-bit]

[ehuss]

Thanks for the report! This was an intentional change as part of rust-lang/rust#103681.

There is an open issue about this at rust-lang/rust#104053, so closing as a duplicate of that.

[uazu]

Thanks. I'll comment there