Repository navigation
libtest should set RUST_TEST_THREADS environment variable #74845
Description
We can configure the test runner concurrency by using either the --test-threads parameter, or by setting the environment variable RUST_TEST_THREADS:
Line 245 in efc02b0
As some tests might need to read the current concurrency configuration, the only way to do this currently is by reading the said environment variable. However, if we use --test-threads, this information is not passed further to tests. I think this behaviour is a bit inconsistent and the env var should be always set to the actual value, e.g.:
let concurrency = opts.test_threads.unwrap_or_else(get_concurrency);
env::set_var("RUST_TEST_THREADS", concurrency.to_string());
Activity
bjorn3 commentedon Jul 27, 2020
I think the name would be ambiguous when using an external process to run the tests (used for
-Cpanic=abortonly targets) It could refer to the total amount of concurrenr threads or the total amount of threads in the current process (1)Use the environment to get number of threads
Deprecate RUST_TEST_* env variables
Rollup merge of rust-lang#145269 - epage:test-env, r=jhpratt
Rollup merge of rust-lang#145269 - epage:test-env, r=jhpratt
Rollup merge of rust-lang#145269 - epage:test-env, r=jhpratt
Rollup merge of rust-lang#145269 - epage:test-env, r=jhpratt
Rollup merge of rust-lang#145269 - epage:test-env, r=jhpratt
Unrolled build for #145269
Rollup merge of rust-lang#145269 - epage:test-env, r=jhpratt
epage commentedon Sep 5, 2025
In #145269, we deprecated
RUST_TEST_*environment variables so this would be less about consolidating information to one place / consistency of information but more of providing a mechanism to tell tests what the concurrency level is.One challenge with tests reading the number of available threads is that is meant to be about constraining resources and the test runner itself is using up all of those resources. Instead, it seems like we'd need tests to acquire and release these resources from the test runner. I feel like us providing our own API for this is unlikely to happen and would end up being left to custom test harnesses. We could defer to jobserver (#48532) but that might be a bit more complicated.
It would help to know what the use case is for why a test knowing the number of threads would matter.