search

cplusplus / sender-receiver

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

[async.ops] Definition of an async operation's environment's ownership seems incorrect #271

Open lewissbaker opened 4 months ago

lewissbaker commented 4 months ago

The wording of P2300R10 [async.ops] p4 states:

An asynchronous operation has an associated environment. An environment is a queryable object ([exec.queryable]) representing the execution-time properties of the operation’s caller. The caller of an asynchronous operation is its parent operation or the function that created it. An asynchronous operation’s operation state owns the operation’s environment.

The last sentence doesn't quite seem right to me.

An operation's associated environment is provided to it by its caller via the receiver. An operation therefore does not really "own" its own environment, but rather is provided access to the environment by its caller.

Can we just strike this sentence from here?

ericniebler commented 4 months ago

do you agree that the operation state takes ownership of the receiver? and that the receiver's environment is the environment of the operation?

lewissbaker commented 4 months ago

Do you agree that the operation state takes ownership of the receiver? and that the receiver's environment is the environment of the operation?

I agree that the operation-state takes ownership of the receiver, and I agree that the environment obtained from the receiver is the environment that is provided to the operation.

However, both the receiver and the environment have handle semantics and they do not necessarily confer ownership of the resulting environment.

I can obtain many instances of the environment queryable object, all of which refer to the same logical environment, by calling rcvr.get_env() multiple times. The storage for values backing an environment's queries are generally (at least in all of the implementations of senders that I've written) provided by the parent operation-states. The environment just holds a pointer to the parent-op-state (just as the receiver holds a pointer to the parent op-state). Destroying the child op-state does not destroy the environment or its values.

I don't think it helps to say that a child operation state "owns" its environment.

lewissbaker commented 1 month ago

A resolution to this issue has been proposed in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3396r0.html