Skip to content

"Cargo test" uses a thread pool in 1.33.0 #58907

Closed
@asomers

Description

@asomers
Contributor

Previous versions of Cargo would create and destroy a new thread for each test. Cargo 1.33.0 instead creates a thread pool and reuses the same thread for multiple tests. This can cause test failures for crates that implicitly rely on Cargo's old behavior for isolation. I'm not saying that the new behavior is wrong, but it deserves a mention in the release notes.

nix-rust/nix#1033

Activity

added
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
A-libtestArea: `#[test]` / the `test` library
on Mar 4, 2019
RalfJung

RalfJung commented on Mar 5, 2019

@RalfJung
Member

There is indeed a change in behavior, but not the way you suggest: behavior only changed for the case of a machine with exactly 1 core. Previously, it would spawn a thread per test and then basically immediately wait on that thread to finish; now instead it runs the tests in the main thread directly. There is no thread pool.

asomers

asomers commented on Mar 5, 2019

@asomers
ContributorAuthor

Perhaps there are two relevant PRs, because I absolutely do see thread-pool-like behavior. Just run strace -e clone cargo test on an n-core system, on almost any crate, for n > 1. With Rust and Cargo 1.33.0 there will be n clones. With older Rust there will be one clone per test.

Actually I just tried again and I'm not seeing that behavior anymore. Perhaps I did something stupid the first time. It may be that the only behavior change is for --test-threads=1.

RalfJung

RalfJung commented on Mar 5, 2019

@RalfJung
Member

Ah yes, indeed it's not about the number of cores but the concurrency level -- which defaults to the number of cores.

Mark-Simulacrum

Mark-Simulacrum commented on Mar 5, 2019

@Mark-Simulacrum
Member

Nominating for libs team -- I expect we'll probably want to not change anything here since the new behavior seems strictly better. However, as a regression, we should discuss.

asomers

asomers commented on Mar 6, 2019

@asomers
ContributorAuthor

I agree that the new behavior is better; Nix shouldn't have been relying on the old behavior. I just think that the new behavior should've been mentioned in the release notes.

Mark-Simulacrum

Mark-Simulacrum commented on Mar 6, 2019

@Mark-Simulacrum
Member

Yep, we missed it when compiling the release notes. If you'd like to propose a PR to master with this added to 1.33.0's notes that'd be appreciated!

alexcrichton

alexcrichton commented on Mar 8, 2019

@alexcrichton
Member

This was discussed during libs triage the other day and the conclusion was that adding this to the release notes is fine, so denominating.

17 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-libtestArea: `#[test]` / the `test` libraryT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ehuss@alexcrichton@asomers@RalfJung@ipetkov

        Issue actions

          "Cargo test" uses a thread pool in 1.33.0 · Issue #58907 · rust-lang/rust