cplusplus / cplusplus/draft

[intro.execution] p11 sequencing of co_await

Open
#4,861 3 comments 0 reactions 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.