Definition of `SCHED-ATTRS` incorrectly assumes that schedule operations that complete with set_stopped will complete on that scheduler

[lewissbaker]

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.

[jiixyj]

I wonder why the senders returned from exec::schedule should be allowed to complete with set_stopped anyway. The current semantics of the scheduler concept (as implied by SCHED-ATTRS) require a set_stopped completion to happen on an execution agent represented by that scheduler. But at that point it might as well complete with set_value, delegating the act of checking/responding to a cancellation request to the following work.

P3284 even proposes to wrap the exec::schedule calls inside schedule_from (and therefore by extension inside continues_on) in unstoppable, making a exec::get_completion_scheduler<exec::set_stopped_t> superfluous AFAICS (edit: ...at least in SCHED-ATTRS). edit3: ...on further thought, the unstoppable would only apply to the schedule sender itself, not to the set_stopped completion from the previous sender that it might propagate on the execution agent.

edit2: In my mind, the only use case for a set_stopped completion of a schedule() sender would be if it wasn't "cheap" to start some work on an execution resource. In that case, start() of the resulting operation state would check for a cancellation request and complete with set_stopped before doing any work. So exactly the inverse meaning of the exec::get_completion_scheduler<exec::set_stopped_t> as specified in SCHED-ATTRS currently. edit3: Striking the last sentence -- the exec::get_completion_scheduler<exec::set_stopped_t in SCHED-ATTRS should only be there for "relaying" set_stopped completions from the previous sender!

[jiixyj]

Sorry for "thinking aloud" in the previous comment. Maybe it becomes clearer when looking at the receiver-type receiver from the schedule_from adapter (https://eel.is/c++draft/exec#schedule.from-9). This is the receiver that is connected to the schedule sender.

struct receiver-type {
    using receiver_concept = receiver_t;
    state-type* state;          // exposition only

    void set_value() && noexcept {
      visit(
        [this]<class Tuple>(Tuple& result) noexcept -> void {
          if constexpr (!same_as<monostate, Tuple>) {
            auto& [tag, ...args] = result;
            tag(std::move(state->rcvr), std::move(args)...);
          }
        },
        state->async-result);
    }

    template<class Error>
    void set_error(Error&& err) && noexcept {
      execution::set_error(std::move(state->rcvr), std::forward<Error>(err));
    }

    void set_stopped() && noexcept {
      execution::set_stopped(std::move(state->rcvr));
    }

    decltype(auto) get_env() const noexcept {
      return FWD-ENV(execution::get_env(state->rcvr));
    }
  };

Looking at this, only if the call to set_stopped of receiver-type does not happen, then it is guaranteed that any set_stopped completions of the whole thing can only happen in the set_value function of receiver-type, thereby making the current formulation of SCHED-ATTRS correct. This can be ensured by one of two things:

• wrapping the call to schedule(sched) inside schedule_from in unstoppable (your option two, also chosen by P3284)
• or requiring that every schedule sender's set_stopped completion completes on an associated execution agent (the status quo). But this is a bit nonsensical as noted earlier, as it might as well complete with set_value then.

Going with unstoppable(schedule(sched)) sounds like the way to go, especially since things like task, async_scope's join and on all require "going back" to the scheduler they started from.

[ericniebler]

@lewissbaker does the proposed resolution of #304 cover this?

[lewissbaker]

I wonder why the senders returned from exec::schedule should be allowed to complete with set_stopped anyway.

The use-case for a schedule() operation completing with set_stopped is when the schedule operation was removed from the queue of things to be executed before running it due to an incoming stop-request.

In this case, the set_stopped completion-function will generally be invoked on the thread that removed the schedule operation from the queue of tasks, rather than on the thread that would have eventually dequeued the item and called set_value.

In this case, it is impossible to know in general which thread/execution-context the stop-request will arrive on and so for most schedule() implementations, we won't know what the completion-scheduler should be for set_stopped results.

@lewissbaker does the proposed resolution of #304 cover this?

@ericniebler No, I don't think so. The proposed resolution in #304 only covers the computation of the completion-signatures and of ensuring that set_error is called on the scheduler's context.

This issue is more about what the result of get_completion_scheduler<set_stopped>() is on a schedule_from() or continues_on() sender and what the behaviour of these algorithms should be if the schedule() operation itself completes with set_stopped.

[ericniebler]

in thinking about the behavior of schedule_from(sch, sndr), i see three distinct ways that it can complete with stopped:

1. the predecessor completes with stopped. in this case, the stopped signal will be propagated on sch (provided the schedule operation completes successfully).

2. the schedule sender is connected to a receiver whose stop token, at the time the operation is started, is already in the "stop requested" state. in that case, the schedule sender may decide to complete with "stopped" synchronously in start.

3. the scheduler sender completes with "stopped" synchronously in start for some other reason. For instance, perhaps its associated execution context has been placed into a "no new work, pls stop" state.

for (1), the status quo (SCHED-ATTRS has sch as its set_stopped_t completion scheduler) is correct. for (2) we can make the status quo correct by wrapping the schedule(sch) sender in unstoppable, but that doesn't help with (3).

my feeling is:

• there may be valid reasons for a scheduler sender to check the receiver's stop token and complete synchronously in start. preventing that (by wrapping the sender in unstoppable in schedule_from) is dubious. what benefit does it bring?
• there may also be valid reasons for an execution context to want its schedule senders to complete synchronously with "stopped". who am i to say?

so, under what conditions can we say anything about schedule_from's set_stopped completion scheduler?

1. if sch is a non-dependent sender and it does not include set_stopped_t() in its sender's completion signatures, we can say that the schedule_from sender, if it completes with "stopped", will do so on sch's execution context.

we can say the same thing about the error completion scheduler also: if we know that sch's schedule sender cannot complete with an error, then the schedule_from's sender can declare sch as its error completion scheduler.

@lewissbaker does this make sense to you?