Skip to content

There's no programmatic way to tell the test runner to run serially #1813

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

Closed
brson opened this issue Feb 12, 2012 · 5 comments
Closed

There's no programmatic way to tell the test runner to run serially #1813

brson opened this issue Feb 12, 2012 · 5 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc

Comments

@brson
Copy link
Contributor

brson commented Feb 12, 2012

I'm working on bindings for a library that cannot be called in parallel and I have no mechanism for enforcing this in my tests. Just a way to create a global handle to a worker task would be enough.

@ghost ghost assigned brson Apr 12, 2012
@bblum
Copy link
Contributor

bblum commented Jul 13, 2013

A cheapo solution would be

#[cfg(test)] fn actual_test_1() { ... }
#[cfg(test)] fn actual_test_2() { ... }
...
#[cfg(test)] fn actual_test_N() { ... }

#[test]
fn run_all_tests() {
    actual_test_1();
    actual_test_2();
    ...
    actual_test_N();
}

but the disadvantage of that should be pretty obvious.

Just a #[serial_test] tag would be overkill, though, since you wanna say what other tests they should be serialized with-respect-to.

One good way to do this would be to use a sync::Mutex, and then have each of the test cases run while holding the mutex, though you couldn't store it as a mutable global. Maybe stash it in TLS?

@emberian
Copy link
Member

Triage bump.

@brson
Copy link
Contributor Author

brson commented Oct 10, 2013

This was never nominated. Unmilestoning.

@reem
Copy link
Contributor

reem commented Sep 3, 2014

Triage. This still would be useful and is still unimplemented.

@brson
Copy link
Contributor Author

brson commented Jan 13, 2015

We have a variety of global synchronization solutions now so this is not the dire problem it was. I don't think its necessary to do anything here.

@brson brson closed this as completed Jan 13, 2015
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc
Projects
None yet
Development

No branches or pull requests

5 participants