Skip to content

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

Open
@skade

Description

@skade
Contributor

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.

Activity

kornelski

kornelski commented on May 12, 2020

@kornelski
Contributor

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

added 3 commits that reference this issue on May 13, 2020

Rollup merge of rust-lang#72141 - kornelski:dontsleep, r=joshtriplett

57003cb

Rollup merge of rust-lang#72141 - kornelski:dontsleep, r=joshtriplett

a54d11f

Rollup merge of rust-lang#72141 - kornelski:dontsleep, r=joshtriplett

d732aef
estebank

estebank commented on May 17, 2024

@estebank
Contributor

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.

2 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-lintArea: New lintsT-async-awaitType: Issues related to async/await

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @skade@kornelski@estebank@phansch@hwchen

        Issue actions

          Lint idea: find known-blocking constructs in async contexts · Issue #4377 · rust-lang/rust-clippy