The SCHED-ATTRS(sch) helper is used in the continues_on() and schedule_from() algorithms and is used to compute the sender-attributes of the sender returned from these algorithms such that they have a get_completion_scheduler<set_value_t> and get_completion_scheduler<set_stopped_t> queries that both return sch.
However, I don't think it's valid to say that a set_stopped result will always complete on the specified scheduler for these algorithms.
In the case that the schedule operation that is trying to transfer execution to the scheduler's context completes with set_stopped, it is not guaranteed that the completion is currently on the scheduler's context (it might be completing synchronously inside a stop-request from an arbitrary thread), and yet the continues_on() operation as a whole will complete with set_stopped, violating the declared get_completion_scheduler<set_stopped_t> query result.
There are a couple of strategies that we can potentially take to eliminate this inconsistency:
We can remove the get_completion_scheduler<set_stopped_t> query from SCHED-ATTRS(sch) and only say things about the completion context of a set_value result.
We can require the schedule operation to complete with set_value - possibly wrapping the schedule operation with unstoppable() and terminate_on_error_and_stopped(), in which case the set_stopped result will only occur if the predecessor completed with set_stopped. This would also allow saying something about the set_error completion scheduler as well.
We can say that the operation as a whole completes with an error if the schedule operation does not complete with set_value (since it failed to meet its post-condition of continuing on that context).
Possibly combining this with an unstoppable wrapper around the schedule operation.
The
SCHED-ATTRS(sch)
helper is used in thecontinues_on()
andschedule_from()
algorithms and is used to compute the sender-attributes of the sender returned from these algorithms such that they have aget_completion_scheduler<set_value_t>
andget_completion_scheduler<set_stopped_t>
queries that both returnsch
.However, I don't think it's valid to say that a set_stopped result will always complete on the specified scheduler for these algorithms.
In the case that the schedule operation that is trying to transfer execution to the scheduler's context completes with set_stopped, it is not guaranteed that the completion is currently on the scheduler's context (it might be completing synchronously inside a stop-request from an arbitrary thread), and yet the
continues_on()
operation as a whole will complete with set_stopped, violating the declaredget_completion_scheduler<set_stopped_t>
query result.There are a couple of strategies that we can potentially take to eliminate this inconsistency:
get_completion_scheduler<set_stopped_t>
query fromSCHED-ATTRS(sch)
and only say things about the completion context of aset_value
result.set_error
completion scheduler as well.unstoppable
wrapper around the schedule operation.