Currently TFRT does not support top-level coroutines, so this functionality will allow to have a single blocking await at the top level until TFRT implements the necessary functionality.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I feel that what is missing from these two revisions is a more contextual description of the motivation and what we're trying to achieve and how, I don't quite have a good understanding of the design just yet.
mlir/lib/Dialect/Async/Transforms/AsyncToAsyncRuntime.cpp | ||
---|---|---|
635–637 | Just & is enough here, unless lambda captures by value don't see a need to specify ref captures explicitly |
Currently TFRT does not support top-level coroutines, so this functionality will allow to have a single blocking await at the top level until TFRT implements the necessary functionality.
I suspect that in general this should be handled using visibility: you should only be able to rewrite the signature of private functions and not public one (which are by definition exported by the module to the outside world): would that be enough to handle the TFRT case?
We'll need to rewrite public functions at some point as well (after resolving all the issues with TFRT threading). Alternatively instead of passing list of function names it can be a boolean flag allow-rewriting-public-functions.
I think this creates an unnecessary and rigid coupling between privacy and asynchronicity, so I'm not a fan of this proposal.
Not to mix visibility and asynchronicity I'd prefer to have a special attribute on functions that should not become async, this will give control to the caller who knows best (e.g. in tfrt currently entrypoint will be marked sync-only).
mlir/include/mlir/Dialect/Async/IR/AsyncDialect.td | ||
---|---|---|
37 | FYI: in C++14 (pre 17) you need a definition in the .cpp file as well to avoid link-time failure in some cases. |
FYI: in C++14 (pre 17) you need a definition in the .cpp file as well to avoid link-time failure in some cases.