El 26/06/2026 a las 20:12, Mungo via Paper-reviews escribió:
Subject: Review request - P4286R0, "P3552: The Return of Networking TS Executors"
Colleagues,
I am requesting a formal review of P4286R0, "P3552: The Return of Networking TS Executors," and would like it read closely. Please all read the same revision, so the summary attaches cleanly to a single document:
Hi,
1. Is the historical trace accurate?
Largely yes. P1525R0 says "The implication is that no generic code can respond to asynchronous errors in a portable way. That prevents higher-level control structures that require flexible error handling from being built" P2464R0 says "A P0443 executor is not an executor. It's a work-submitter. It doesn't provide any means of finding out whether the work submitted succeeded, or whether an error occurred. Such error handling is fundamental and crucial" P3552R3 says "it seems reasonable to require that a scheduler used with affine_on is infallible
2. Did the use of AI affect your perception?
The use of AI makes the paper sometimes "unnatural" to read but I think the facts hold as quotes are exact. I certainly think that the AI-produced output is sometimes inconsistent and too verbose to be easily verifiable for a human trying to follow the arguments and putting things in several papers disperses the information IMHO.
3. Is the structural claim sound?
I think so, but there are some subtleties. P3941R4 achieves infallibility by exclusion: a fallible scheduler may not be used with affine_on; it must be adapted: "If constraining affine_on to only infallible schedulers turns out to be too strong, the constraint can be relaxed in a future revision of the standard by explicitly opting out of that constraints, e.g., using an additional argument"
4. What is missing, and where is the argument weakest?
I haven't evaluated, and certainly don't have the skills to analyze the differences between a IO scheduler that IO coroutines propose (where the OS can offer some guarantees) vs a "general", pure-compute or GPU-oriented scheduler that Sender/Receivers target. It's possible that some criticisms that were applicable to Networking TS could not be applied to the general framework. Best, Ion