search

cplusplus / sender-receiver

Issues list for P2300
Apache License 2.0
20 stars 3 forks source link

Walking receiver and operation state chains #79

Open ericniebler opened 10 months ago

ericniebler commented 10 months ago

Issue by ericniebler Saturday Aug 27, 2022 at 15:22 GMT Originally opened as https://github.com/NVIDIA/stdexec/issues/584

Fact 1: All operation states store the receiver of the enclosing (parent) async scope.

Fact 2: The vast majority of receivers store little more than a pointer back to the operation state for the current async scope.

Implication: If we follow these chains -- operation state -> parent receiver -> parent's operation state -> grandparent's receiver, etc -- we are essentially performing an async stack walk.

The ability to traverse the async stack can be useful in a number of scenarios. Libunifex has a dedicated "visit_continuations" mechanism for doing just this.

Q: Should we require all operation states to expose their parent's receiver, and require that all receivers can return pointers to their operation states[^1]?

[^1]: Obvs some receivers like sync_wait's are terminal and don't have an associated operation state, so we can't require it of all receivers.

ericniebler commented 10 months ago

Comment by ericniebler Saturday Aug 27, 2022 at 15:34 GMT

Note: this would be a way to explore from inner-to-outer async scopes. When we have previously discussed "operation state queries", the hope for those was to explore from outer-to-inner scopes, which is problematic because there isn't a simple 1-to-1 parent-to-child relationship with async scopes as there is with child-to-parent relationships.