Split fast path ignores receiver’s scheduler leading to mismatched completion thread

[shlokjain2031]

Problem
When split replays a cached result on the fast path (predecessor_done == true), it calls set_value inline on the thread that calls add_continuation(). This ignores the receiver’s completion scheduler returned by get_completion_scheduler<set_value_t>(get_env(receiver)).

There is a TODO in split.hpp#L349 around the fast-path that mentions preserving the scheduler, but the current implementation does not propagate it.

Observed behavior from a demo file

shlokjain@Shloks-MacBook-Pro-2 hpx %  /Users/shlokjain/hpx/split_fastpath_scheduler_violation_demo
=== split fast-path scheduler mismatch (HPX split only) ===

Predecessor completed on thread 0x1eecea0c0 with value=42

UI scheduler thread id : 0x16d3cb000
Main thread id          : 0x1eecea0c0

Connecting split sender from MAIN thread to a receiver that expects the UI scheduler...

set_value called with value=42
  expected scheduler(UI) thread id: 0x16d3cb000
  actual completion thread id     : 0x1eecea0c0
  match? NO

Demo finished.

Reproduce
Minimal standalone demo

[shlokjain2031]

My approach is to query the receiver’s environment for the appropriate completion scheduler and if a valid scheduler is found, we schedule the completion and deliver set_* via scheduled continuation instead of inline

We can fallback to the current implementation if there is no valid completion scheduler available.

I would be happy to discuss further implementation details, thanks:)

[hkaiser]

My approach is to query the receiver’s environment for the appropriate completion scheduler and if a valid scheduler is found, we schedule the completion and deliver set_* via scheduled continuation instead of inline

We can fallback to the current implementation if there is no valid completion scheduler available.

I would be happy to discuss further implementation details, thanks:)

This sounds to be correct. Don't we do that already?

[shlokjain2031]

I don’t think so. In add_continuation, when predecessor_done is already true, we directly invoke set_* via the visitor inline. That executes the completion on the thread calling add_continuation, without querying or scheduling on the receiver’s completion scheduler. So the scheduler is not preserved in that path.
Referring to split.hpp#L343-L355