Thank you writing this interesting paper and putting in the work to advance the state of C++. I am not an expert in networking. I am not an expert in coroutines. I am somewhat an expert in academic writing. So I will not answer questions I'm not qualified to answer, and instead give my two cents about the form of the argumentation that is IMO the most serious hindrance towards reading and acceptance. The abstract does not follow the standard rule of guiding new readers toward the problem at hand. I understand standard papers are terser than academic, but terse is no excuse for context-free. Usually the abstract should funnel the reader progressively from broad context to the specific contribution. The present abstract does the opposite: - no opening content - it drops us straight into the co_await f() code, - no problem statement and no indication why we should care - It does not mention whether the problem exists in the real world - and does not explain why the committee should spend time on it A more useful abstract could look like this (I'm no networking expert, so please forgive probable mistakes, it's just to illustrate my point:
(broadest context) C++20 coroutines are now widely used for asynchronous code, but the language deliberately left the execution model unspecified. The standard library provides no common vocabulary for the three decisions every suspended coroutine must make.
(narrowing) As a result, every coroutine library reinvents incompatible specifications of how a coroutine decides which thread it resumes on, whether it should be cancelled, and where its frame memory comes from. This fragmentation prevents tasks, awaitables, executors, and launch functions from different libraries from interoperating, and it leaves frame allocation (the dominant coroutine cost) without a standard customization point. (narrowing further to the specific method, high level vision) This paper proposes the IoAwaitable protocol: a minimal coroutine execution model supplying exactly three things: executor affinity, stop-token propagation, and frame-allocator delivery. (specific method, low level vision: precise contribution, bring evidence) The protocol is small (a handful of concepts: IoAwaitable, IoRunnable, Executor, execution_context) yet enables interoperable tasks, executors, and launch functions across libraries. It is a companion to P2300 std::execution rather than a competitor. The design has a complete implementation on three platforms, with measured frame-allocator speedups up to 3.1×. This paper asks LEWG to advance it as a standard coroutine execution model. <<< Many terms are used but not defined, even loosely: - interoperable tasks - frames - executor affinity - stop token propagation etc etc One could argue those are such basic terms in the context of this paper - and I'd agree. However, one clear thing from my understanding of standardization meetings is that people are often not experts in the specific problems being treated. Lowering the friction for them to understand your contribution's value in their context is strategically worth your time if you want your proposal to advance. Without becoming a 101 class on coroutines, a good introduction must give intuition about the most fundamental aspects the paper proposes to advance. It goes hand in hand with making the paper more self-contained, as previously mentioned. Defining terms briefly in the introduction and/or providing a more detailed list in a glossary at the end are standard ways to ensure people follow and use the same definitions as you do, reducing useless debate around terminology.
The left column is small. The right column is not. Small protocol, big rewards. It earns its keep.
Value claims should be argued and demonstrated, not sloganized. This should not pass editing.
See P4172R0 [1] for design rationale and analysis of alternativeapproaches
Like in programming, pulling too many references increases the reader's cognitive load, fatigue and frustration. Consider whether a quick summary of those papers (take home message) could advance your point more efficiently. Several passages read as over-compressed, to the point of limiting readability and impacting understanding:
What follows is the minimum. What follows is the minimum as well.
This is not an efficient way to introduce an entire section. I would recommand giving a high-level vision of what will be treated in the three sub-sections and why. Readers must be prepared for what follows, otherwise they will reach the end of the subsections overwhelmed by technical details disconnected from the high-level understanding and stakes.
The minimal statement that suspends a coroutine:
It lacks context: is it proper to this proposal, is it a generally agreed on design, what is the rationale, etc.
But on which thread? Under whose control? (duplicated in code snippet)
The rhetorical-question register is inappropriate for a normative proposal, and it is repeated verbatim in the code comment.
Executor affinity, stop token propagation, frame allocator delivery. Three concerns. One protocol. A companion to std::execution, implemented on three platforms. Nothing in it can be removed.
This is not a proper conclusion, this is a slogan. And it risks delegitimizing the paper. A conclusion should tell the reader what to take away now that they have the full argument. In its current form: someone who read the paper learns nothing new, and someone who did not read the paper learns nothing. "Nothing can be removed" is a minimality claim that can be proved true or false but was never justified/explored in the paper.The paper asks for advancement from LEWG, but the conclusion dodges this request. The conclusion is the natural place to state simply: i) what advancing this enables, ii) what fragmentation costs if you don't, and iii) why this is the right minimal layer to standardize now and not later. A proper conclusion should funnel the reader out: - restate the contribution - widen to significance and consequences - what does C++ gain if you accept it, and what does it lose if you don't - who builds on it - what's the relationship to the wider context (frameworks and libraries, std::execution etc) Overall the paper: - reflects a lot of work behind the scenes - is not self-contained and will frustrate the reader - does itself a disservice by emptying sections of rationale and justification: the reader is expected to subliminally accept that this proposal is superior to alternatives - does not walk people in, does not walk people out - reads in places as heavily compressed, possibly auto-summarized, at a real cost to readability Thank again for giving us this interesting opportunity to review this work. I am excited about seing what comes next. Best wishes, Arnaud Becheler