Feat/fork join executor p2300 bridge

[shivansh023023]

executors: Add P2300 get_scheduler bridge for fork_join_executor

Fixes #5219 (partial)

Proposed Changes

• Added free tag_invoke(get_scheduler_t, fork_join_executor const&)
  outside the class body, returning
  executor_scheduler<fork_join_executor>, so that the return type is
  fully defined at point of use
• Replaced executor_scheduler_fwd.hpp include with the full
  executor_scheduler.hpp to ensure type completeness
• Added tag_invoke(post_t, fork_join_executor const&) delegating to
  async_invoke so the generic executor_scheduler operation state
  can dispatch work onto the fork_join thread pool
• Extended fork_join_executor unit tests with test_get_scheduler()
  verifying scheduler acquisition, work dispatch, and thread identity

Background

fork_join_executor is one of HPX's primary performance executors used
for NUMA-aware work-stealing. Without a get_scheduler bridge it cannot
participate in P2300 pipelines using continues_on, transfer, or
let_value. After this PR:

hpx::execution::experimental::fork_join_executor exec{};
auto sched = hpx::execution::experimental::get_scheduler(exec);
stdexec::sync_wait(
    stdexec::then(stdexec::schedule(sched), []{ return 42; }));

This follows the pattern established for sequenced_executor (#7238)
and parallel_executor (#7239).

Checklist

• I have added a new feature and have added tests to go along with it.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[StellarBot]

Can one of the admins verify this patch?

[shivansh023023]

Thank you for the reviews! I have addressed all feedback:

Replaced async_invoke with sync_invoke in the post_t overload
to avoid creating a ready-future that is immediately discarded.

Moved executor_scheduler_fwd.hpp out of the fwd/ subdirectory
since the _fwd suffix already conveys its purpose.

Replaced the internal #include <hpx/executors/executor_scheduler.hpp>
in the test file with #include <hpx/modules/executors.hpp>.

I initially added is_one_way_executor<fork_join_executor> as suggested,
but it caused the existing bulk dispatch chain to route through
sync_execute, which fork_join_executor does not implement — it is
bulk-only. All existing bulk tests failed as a result. I have reverted
this specialization. Happy to revisit if there is a preferred approach.

[hkaiser]

I initially added is_one_way_executor<fork_join_executor> as suggested,
but it caused the existing bulk dispatch chain to route through
sync_execute, which fork_join_executor does not implement — it is
bulk-only. All existing bulk tests failed as a result. I have reverted
this specialization. Happy to revisit if there is a preferred approach.

I should have said is_never_blocking_one_way_executor.

[shivansh023023]

I initially added is_one_way_executor<fork_join_executor> as suggested,
but it caused the existing bulk dispatch chain to route through
sync_execute, which fork_join_executor does not implement — it is
bulk-only. All existing bulk tests failed as a result. I have reverted
this specialization. Happy to revisit if there is a preferred approach.

I should have said is_never_blocking_one_way_executor.

@hkaiser
Thank you for the correction! I have added
is_never_blocking_one_way_executor<fork_join_executor> instead.

[hkaiser]

@shivansh023023 We have merged #7257 now. You can go ahead and review and update all of your PRs related to senders&receivers now. Thanks!

[shivansh023023]

@shivansh023023 We have merged #7257 now. You can go ahead and review and update all of your PRs related to senders&receivers now. Thanks!

Okay

[hkaiser]

@shivansh023023 inspect reports

/libs/core/executors/src/fork_join_executor.cpp: *I* missing #include (type_traits) for symbol std::underlying_type_t on line 31

Also, the new test doesn't compile. Please fix. I'd appreciate it if you had an eye on the CI yourself in the future.

[shivansh023023]

@hkaiser I added the missing <type_traits> include and got the unit test compiling which made the Inspect check pass . I did notice the 18-execution-lcos_distributed check crashed during the linking phase. Since this PR is strictly isolated to the local fork_join_executor files, I'm pretty sure that's just an unrelated CI runner hiccup or an out-of-memory issue.

[hkaiser]

@hkaiser I added the missing <type_traits> include and got the unit test compiling which made the Inspect check pass . I did notice the 18-execution-lcos_distributed check crashed during the linking phase. Since this PR is strictly isolated to the local fork_join_executor files, I'm pretty sure that's just an unrelated CI runner hiccup or an out-of-memory issue.

Currently it fails because of an obsolete use of tag_invoke. Could you please have a look?

[shivansh023023]

@hkaiser I checked the logs for the 18-execution-lcos_distributed failure. It looks like a single test out of 1,293 failed due to a pure timeout (tests.unit.modules.runtime_components.distributed.tcp.refcnted_symbol_to_remote_object).
Since this PR is strictly confined to local execution and doesn't touch the distributed TCP or remote object layers, this is an unrelated infrastructure timeout

[shivansh023023]

@hkaiser any updates sir?