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).