-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libtest: run all tests in their own thread, if supported by the host #103681
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
I'll need to do some testing to ensure the test harness still works on Windows, which has less complete threading support in Miri than Unix targets. |
This comment was marked as resolved.
This comment was marked as resolved.
Unfortunately on the Miri side of this is blocked on rust-lang/miri#2628. |
7e039e0
to
f7f381e
Compare
f7f381e
to
3af058e
Compare
On many-core systems it could be useful to use a thread pool rather than a thread-per-test to avoid the thread-spawning costs (e.g. contention on the memory-map lock for the thread stack creation). Maybe updating the thread name between tests could work? |
Sure, but that's a new feature I won't implement. All this here does is revert a PR I wrote years ago. It doesn't even change behavior for many-core systems, it only changes behavior for
The standard library doesn't have an API for that. Also see #70492. |
rust-lang/miri#2630 adds the missing thread parker support for Windows. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, I had no idea the reason miri was the reason for this part of libtest's cruftiness.
Really glad to see it gone either way, it vaguely was in the way of a few other things I've wanted to do for a while now.
r=me once you're ready to land it.
What about inherently single threaded environments like wasm? Won't this break libtest for those? As far as I am aware wasm32-wasi currently supports using libtest. |
@bjorn3 the "if supported by the host" part should take care of that. Ctrl-F |
Missed that, my bad. |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#103367 (Remove std's transitive dependency on cfg-if 0.1) - rust-lang#103397 (Port `dead_code` lints to be translatable.) - rust-lang#103681 (libtest: run all tests in their own thread, if supported by the host) - rust-lang#103792 (Migrate `codegen_ssa` to diagnostics structs - [Part 2]) - rust-lang#103897 (asm: Work around LLVM bug on AArch64) - rust-lang#103937 (minor changes to make method lookup diagnostic code easier to read) - rust-lang#103958 (Test tidy should not count untracked paths towards entries limit) - rust-lang#103964 (Give a specific lint for unsafety not being inherited) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Rust default test harness doesn't really work for anything on macOS that requires execution on main thread. Unfortunately main thread is special (so that on some places there are actually checks for pthread_main_np, i.e. in libdispatch. It would be immensely helpful if there was way to run tests with the default harness directly on main thread. |
@knopp comments on old merged MRs are unlikely to lead anywhere. Please open a new issue to describe the problem. |
See e.g. #104053 |
This reverts the threading changes of #56243, which made it so that with
-j1
, the test harness does not spawn any threads. Those changes were done to enable Miri to run the test harness, but Miri supports threads nowadays, so this is no longer needed. Using a thread for each test is useful because the thread's name can be set to the test's name which makes panic messages consistent between-j1
and-j2
runs and also a bit more readable.I did not revert the HashMap changes of #56243; using a deterministic map seems fine for the test harness and the more deterministic testing is the better.
Fixes #59122
Fixes #70492