-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
|
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.
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.
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.
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 ( The exhaustive check might never land on Adding a top-level attribute feels like a waste, and restricting it to the CC @weiznich Edit: created rust-lang/rfcs#3639 proposing this. |
With
async/await
coming up, we will probably see an uptake of such code: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 famouslyto_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.
The text was updated successfully, but these errors were encountered: