[llvm-dev] [clang-tidy][RFC] checks concurrency-async-{blocking, fs, no-new-threads}
Vasily Kulikov via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 27 10:45:07 PST 2021
Hi,
Thank you for the comment!
David Chisnall:
> It is possible that coroutine code in the wild isn't doing many deep
> function calls as more general code, in which case it's quite plausible
> that a simple clang-tidy check would be sufficient. I worry that a
> deny-list approach is going to be far less maintainable than an
> allow-list though: in POSIX there are a handful of system calls that can
> block, but in win32 there are vastly more and higher-level APIs such as
> Qt have a massive API surface.
Agreed. I don't want the solution that's hard to maintain too.
> A list of C++ standard-library functions that are safe to call in
> coroutines seems plausible to maintain. I wonder if the right approach
> is a [[clang::coroutine_safe]] attribute that we can put on libc++
> functions, methods, and classes (if all methods are safe to call, or
> with a [[clang::coroutine_unsafe]] variant for methods where the default
> has been defined). We could then have a checker that warns if you call
> a function that isn't marked as coroutine-safe from a coroutine or from
> a function that is marked as coroutine-safe.
Hm, the attribute sounds interesting. And if it becomes widespread, it could be
proposed for the next standard...
However, it would suffer from the same "WL somewhere, BL somewhere" issue - it's
relatively simple to mark with [[clang::*]] for LLVM's code, it would be harder
for glibc/boost, and it will be impossible for third-party libraries we may not
commit to. The problem is almost the same as with noexcept or const - if the
keyword is not set, you may not be certain whether it is intentional or the
method really throws/changes *this.
Btw, for a full replacement of the PRs there should be at least the 2nd
attribute for "no fs access". I expect there are many projects that tolerate fs
access from coroutines as there is no fs thread pool. It's not obvious to me
what the solution should be here (if any).
More information about the llvm-dev
mailing list