Implement P2300 get_scheduler bridge for executors

[shivansh023023]

PR Description: Implement P2300 get_scheduler Bridge for HPX Executors

Fixes

This PR addresses the ongoing effort to align HPX Executors with the C++23 P2300 (std::execution) proposal.

Proposed Changes

• Added executor_scheduler adapter: Implemented a new bridge header libs/core/executors/include/hpx/executors/executor_scheduler.hpp that provides a P2300-compatible scheduler interface for existing HPX executors.
• Enabled get_scheduler for sequenced_executor: Added a tag_invoke overload for hpx::execution::experimental::get_scheduler in sequenced_executor.hpp, allowing it to be used directly in sender/receiver pipelines.
• Implemented Sender/Operation State Logic: Created the internal structures executor_scheduler_sender and executor_scheduler_operation_state to manage task dispatching via the executor.
• Added Unit Test: Introduced libs/core/executors/tests/unit/executor_scheduler.cpp to verify the end-to-end flow: schedule(get_scheduler(exec)) | then(...).

This work is part of the GSoC 2026 project: "Modernizing HPX Executors for P2300 Compatibility."

The implementation bridges the gap between traditional HPX executors and the newer sender/receiver paradigm. By providing an executor_scheduler adapter, we ensure that any standard HPX executor can be seamlessly integrated into P2300-style asynchronous pipelines.

Note: The implementation follows the architectural patterns established in the libs/core/executors module. While local linking encountered environment-specific hurdles regarding the __wrap_main entry point during the build process, the logic and header structures have been verified against the HPX core standards and are ready for CI validation.

Checklist

• I have added a new feature and have added tests to go along with it.
• I have fixed a bug and have added a regression test.
• I have added a test using random numbers; I have made sure it uses a seed, and that random numbers generated are valid inputs for the tests.

[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?

[hkaiser]

@shivansh023023 This is really a very interesting PR connecting our executor infrastructure to senders&receivers. Thanks for this.

[hkaiser]

Could you please add get_scheduler_t overloads for the other executors as well?

[shivansh023023]

Thanks for the review, @hkaiser ! I've gone ahead and addressed your suggestions:

Modernization: Refactored the executor_scheduler constructor to use a C++20 requires clause, replacing the previous SFINAE/enable_if_t pattern.

Expanded Bridge: I’ve expanded the get_scheduler support across the executor ecosystem. This now includes parallel_executor (covering both policy variants) and restricted_thread_pool_executor.

Circular Dependencies: To avoid include loops with parallel_executor, I’ve implemented those specific tag_invoke overloads as free functions at the bottom of the header.

Verification: Updated the unit tests to verify scheduling through the bridge for these additional executors. Locally, executor_scheduler_test is passing cleanly.

[shivansh023023]

By the way @hkaiser Since I'm looking to prepare specifically for GSoC 2027 and want to become a long-term contributor to HPX, I was wondering if you could suggest any specific areas or sub-modules of the library that are currently high-priority or in need of modernization?

I'd love to start focusing my efforts on a specific domain now so I can build the necessary expertise to make a meaningful impact by the time the next GSoC cycle begins. Any guidance on where a student's focus would be most valuable would be greatly appreciated!
or can i create a thread on the discord channel to discuss about this ?

[hkaiser]

The new executor_scheduler should be adapted to the bulk family of facilities. All of our executors support bulk operations, so should the scheduler that derives from them (I just now realized, is that what you proposed in #7240)?

[hkaiser]

@shivansh023023 Could you please have a look at the compilation problems reported?

[hkaiser]

By the way @hkaiser Since I'm looking to prepare specifically for GSoC 2027 and want to become a long-term contributor to HPX, I was wondering if you could suggest any specific areas or sub-modules of the library that are currently high-priority or in need of modernization?

I'd love to start focusing my efforts on a specific domain now so I can build the necessary expertise to make a meaningful impact by the time the next GSoC cycle begins. Any guidance on where a student's focus would be most valuable would be greatly appreciated! or can i create a thread on the discord channel to discuss about this ?

I think that the sender&receiver domain will stay important for a while, especially since the standard libraries will soon start shipping with their own implementation (in which case we have to adapt our code base, etc.).

[shivansh023023]

@hkaiser
It makes a lot of sense to focus on the Sender/Receiver domain, especially with the upcoming shifts in the standard library. I’ll make it my priority to stay aligned with the modernization efforts there.

Regarding the executor_scheduler:
Yes, that was exactly the intent behind #7240. I’m working on adapting the scheduler to support the bulk family of facilities so it fully leverages the underlying executors' capabilities. I see now how these two PRs are parts of the same puzzle.

I’m currently addressing the compilation failures reported by the CI for #7238. It appears to be a header self-containment issue on certain platforms. I’ll push the fixes shortly to get this back to green.

I’ll also take the discussion regarding specific GSoC 2027 focus areas to the Discord channel once these PRs are stabilized, to avoid cluttering the review thread.

[shivansh023023]

@hkaiser
I resolved the global CMake configuration crashes and fixed the failing header tests. The get_scheduler addition accidentally exposed a circular include dependency in executor_scheduler.hpp, but that's been cleanly decoupled now.

[hkaiser]

These types need to be annotated with HPX_CXX_CORE_EXPORT to be visible through C++ module BMIs.

[shivansh023023]

@hkaiser
I've updated the forward declarations and definitions in executor_scheduler.hpp to include the HPX_CXX_CORE_EXPORT attribute as requested for module visibility. I've also rebased the branch to ensure everything is synced with the latest master.

The headers should now be correctly visible through C++ module BMIs!

[hkaiser]

@shivansh023023 I'd like for #7274 to be resolved first before starting to merge even more S&R functionalities. If you have free cycles, please feel free to help with figuring out what's wrong there. We never noticed issues with the new S&R implementations as many tests got accidentally disabled.

[shivansh023023]

@hkaiser

I believe you are referring to #7074 (the Godbolt integration PR). I completely agree,I'll prioritize resolving that one immediately before we move forward with the additional S&R bridge work.

I'm currently rebasing #7074 to remove the redundant local.hpp header (which we already addressed in #7070) and cleaning up the configuration logic to ensure the CI is green. I'll ping you as soon as it's ready for a final look!