[intro.execution] p11 sequencing of co_await
Nobody has claimed this yet.
- Dominant language
- TeX
- Stars
- 221
- Forks
- 813
- Avg merge
- 16h 4m
- Merged PRs (30d)
- 36
Description
[basic.exec.intro.execution] p11
For each function invocation or evaluation of an await-expression F, each evaluation that does not occur within F but is evaluated on the same thread and as part of the same signal handler (if any) is either sequenced before all evaluations that occur within F or sequenced after all evaluations that occur within F; if F invokes or resumes a coroutine ([expr.await]), only evaluations subsequent to the previous suspension (if any) and prior to the next suspension (if any) are considered to occur within F.
For invoking a coroutine(F is a coroutine call), the current wording seems to have no big problem. However, for co_await expression(IIUC, F refers to the co_await expression), It is a bit vague. I try to use the following illustration(not a c++ code) to expound on the problem I'm concerning. For concisely, ignore the suspension produced by initial-suspend and final suspend or they do not suspend a coroutine.
functionA(){
// just talk about the suspension produced by user-written co_await expression
// as per [expr.await], evaluate a single co_await consists of:
1: o expression
2: r = await-ready
3: r == false then suspension // #1
4: await-suspend
break point // #2
5: await-resume
}
int main(){
functionA();
// #3
evaluation B
resume functionA
evaluation C
}
Firstly, I don't know why we need to say F resumes a coroutine. Consider line 1,2,3,4,5 is a complete evaluation of a single co_await expression(if ignore the suspension), when evaluating this co_await expression, if r is false, then at that point, the coroutine is considered suspension, assume await-suspend is a prvalue of type void, the control flow will back to #3, which means in this perspective, the evaluation 1, 2, 3, 4 should be considered to occur within F since evaluation B will be evaluated, which means line 5 is not considered occur within F at this point, otherwise evaluation B cannot be evaluated until at least line 5 has been evaluated. In this example, F does not resume any coroutine.
Moreover, consider at the beginning of evaluating the co_await expression, #1 is the next suspension, however, the line 4 still needs to be evaluated but it is after the "next suspension" point, in other words, the line 4 should be considered to occur within F. The above rule does not fit here.
When we back to #2 by "resume functionA", line 5 is considered to occur within F since it is subsequent to the previous suspension #1, which means "evaluation C" is either before or after the line 5.
Instead, in terms of the current wording, does it permit that the evaluation B could be sequence after 1, 2, 3? Since for function(coroutine) invoke F and co_await F', only 1, 2, 3 are considered to occur within F and F'.
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.
Research direction
Start with [basic.exec.intro.execution] paragraph 11 and the referenced [expr.await] rules. Trace the issue's numbered coroutine evaluations through suspension and resumption, then determine whether the sequencing wording is coherent for both invocation and co_await. Done means an agreed interpretation or revised standard wording that resolves the examples.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100