Skip to content
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

Lint idea: find known-blocking constructs in async contexts #4377

Open
skade opened this issue Aug 13, 2019 · 3 comments
Open

Lint idea: find known-blocking constructs in async contexts #4377

skade opened this issue Aug 13, 2019 · 3 comments
Labels
A-lint Area: New lints T-async-await Type: Issues related to async/await

Comments

@skade
Copy link
Contributor

skade commented Aug 13, 2019

With async/await coming up, we will probably see an uptake of such code:

async hello() {
    println!("hello").
}

Users will most likely not be aware that the call to println are blocking. The same goes to any use of the stdlib io apis, most famously to_socket_addr() calls.

I think there is a chance for clippy to at least find obvious cases of this, for a list of known functions.

@hwchen
Copy link

hwchen commented Nov 25, 2019

thread::sleep seems to be a pretty common mistake:

https://old.reddit.com/r/rust/comments/e1gxf8/not_understanding_asyncawait_properly/
https://old.reddit.com/r/rust/comments/dtp6z7/what_can_i_actually_do_with_the_new_async_fn/
https://old.reddit.com/r/rust/comments/dt0ruy/how_to_await_futures_concurrently/

@kornelski
Copy link
Contributor

thread::sleep is a major offender. I've found that mistake done several times in a real-world codebase.

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 13, 2020
Warn against thread::sleep in async fn

I've seen `thread::sleep` wrecking havoc in async servers. There's already an [issue for clippy](rust-lang/rust-clippy#4377), but the std docs could warn against it too.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 13, 2020
Warn against thread::sleep in async fn

I've seen `thread::sleep` wrecking havoc in async servers. There's already an [issue for clippy](rust-lang/rust-clippy#4377), but the std docs could warn against it too.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 14, 2020
Warn against thread::sleep in async fn

I've seen `thread::sleep` wrecking havoc in async servers. There's already an [issue for clippy](rust-lang/rust-clippy#4377), but the std docs could warn against it too.
@estebank
Copy link
Contributor

estebank commented May 17, 2024

I'm currently working on a linter that does exhaustive call-graph analysis to detect indirect usages of blocking calls in async functions. Right now this is working well, and requires either annotations (#[redpen::blocking]) or adding a fully-qualified path to a list ::std::thread::sleep).

The exhaustive check might never land on rustc itself due to perf considerations (although I would love if it could be upstreamed to clippy once its more mature) but we can lint on the "simple"/direct case (async fn foo(t: Duration) { sleep(t) }) relatively easily. In order to do that, it'd be a good idea to add an annotation for blocking to the language.

Adding a top-level attribute feels like a waste, and restricting it to the clippy feels wrong, but we now have the #[diagnostic] namespace, so we could annotate std::thread::sleep and the like with #[diagnostic::blocking] for the benefit of both rustc and clippy to lint against direct uses (and my tool can get those attributes itself for its analysis and lint against indirect uses) and it provides crate authors a way to specify that their functions are blocking and their incorrect direct usage will also get linted.

CC @weiznich

Edit: created rust-lang/rfcs#3639 proposing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints T-async-await Type: Issues related to async/await
Projects
None yet
Development

No branches or pull requests

5 participants