Is a coroutine considered suspend after evaluating the await-suspend expression for the final suspend point
@tkoeppe is already working on this.
Since Apr 16, 2021.
- Dominant language
- TeX
- Stars
- 221
- Forks
- 813
- Avg merge
- 16h 4m
- Merged PRs (30d)
- 36
Description
Assume the operand of the expression co_await promise.final_suspend() has std::always_suspend type. That means after evaluating the associated await-ready expression, the coroutine should be considered in a suspending state and then transfer the control to the caller or resumer after evaluating the await-suspend expression.
If the result of await-ready is false, the coroutine is considered suspended.
Then invoking resume() for the coroutine will result in a crash in most major implementations(GCC, clang). But, invoking destroy() is ok. The current draft is underspecified for what the status is.
There are only little hints in section [support.coroutine]
support.coroutine#coroutine.handle.observers-3
true if the coroutine is suspended at its final suspend point, otherwise false.
support.coroutine#coroutine.handle.resumption-2
Preconditions: The coroutine is not suspended at its final suspend point.
If merely according to what [expr.await#5] says, the coroutine should be considered in a suspending status. IIUC, the preconditions above intend to state that when calling resume for a coroutine after evaluating the associated await-suspend expression for the final suspend point, the coroutine is as if it's not in suspending status at this point. Should we make the rule be a normative rule defined at [dcl.fct.def.coroutine]?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.