Skip to content

Clarify completion scheduler semantics for timed scheduler fallbacks #2165

Description

@fallintoplace

Related: #2164

PR #2164 restores get_completion_scheduler<set_value_t> on the lazy fallbacks for schedule_at and schedule_after.

The implementation can inspect the type of the completion scheduler returned by the native timed sender, but then returns the scheduler passed into the fallback. This is correct if timed_scheduler requires native timed operations to complete on that exact scheduler value. However, timed_scheduler currently only requires schedule_at and schedule_after to return senders.

For example, a scheduler S{context_a} could return a sender whose completion scheduler is S{context_b}. The types match, but the execution resources do not. The fallback would advertise context_a even though the native sender completes on context_b.

There is also a cv/ref question. The native sender type is probed using _Scheduler, but the actual call happens later from a non-mutable lambda and sees the captured scheduler as const S&. Ref-qualified overloads can therefore produce a different native sender type from the one inspected by the fallback.

Could we clarify the intended contract?

  1. If schedule_at and schedule_after must complete on the supplied scheduler value, should timed_scheduler document or require that?
  2. If not, should the fallback omit the completion-scheduler query unless equality can be established?
  3. Should the fallback also preserve completion-scheduler queries that depend on the receiver environment, or is that out of scope?

The fallback must keep now() lazy. Issue #847 explains why computing the native sender eagerly is not equivalent.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions