Implement P2300 bulk adapter for HPX executors by shivansh023023 · Pull Request #7240 · TheHPXProject/hpx

shivansh023023 · 2026-05-02T17:39:21Z

P2300 `bulk` Integration for HPX Executors

Description

This PR implements the P2300 bulk sender adapter specifically for HPX's legacy executors, including the parallel_executor and sequenced_executor. By bridging the hpx::execution::experimental::bulk algorithm with HPX's internal bulk_sync_execute mechanism, this change ensures that data-parallel workloads are properly load-balanced and optimized using HPX's high-performance partitioners.

Key Technical Improvements:

Algorithmic Bridging: Successfully mapped the C++23 bulk sender to the underlying HPX execution engine for native parallel performance.
Robust tag_invoke Overloads: Implemented a full suite of connect_t overloads (supporting &&, &, and const&) to ensure compatibility with consumer algorithms like sync_wait.
Reference Stability: Utilized std::decay_t within the bulk_receiver to prevent reference collapsing and ensure the safety of deferred functional object execution.
Architectural Integrity: Resolved a potential circular dependency by situating the implementation within the executors module rather than the core execution module.

Proposed Changes

[New] libs/core/executors/include/hpx/executors/executor_scheduler_bulk.hpp: Implements executor_bulk_sender and executor_bulk_receiver.
[Modified] libs/core/executors/include/hpx/executors/executor_scheduler.hpp: Exposes get_completion_scheduler_t for ADL discovery.
[Modified] libs/core/executors/include/hpx/executors/parallel_executor.hpp & sequenced_executor.hpp: Integrated the new bulk headers.
[New Test] libs/core/executors/tests/unit/executor_algorithm_bulk.cpp: Comprehensive validation for sequential and parallel policies.

Background context

This work is part of the ongoing effort to modernize HPX's execution model to align with the C++23 Sender/Receiver (P2300) standard. Implementing bulk is a "Big Impact" milestone because it allows modern asynchronous pipelines to tap into the mature, multi-threaded performance of the HPX runtime.

Checklist

I have added a new feature and have added tests to go along with it.
I have verified the implementation with a local build of the executor_algorithm_bulk_test target.
I have ensured all includes are strictly alphabetically sorted to comply with the HPX inspect tool.

StellarBot · 2026-05-02T17:40:04Z

Can one of the admins verify this patch?

codacy-production · 2026-05-02T17:42:17Z

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.}

hkaiser · 2026-05-03T15:11:47Z

@shivansh023023 Just FYI, before you invest more time into our old sender/receiver implementation: #7123 will soon remove almost all of our code related to this. Please focus your efforts on whatever stays after this has been merged.

shivansh023023 · 2026-05-05T19:30:04Z

@hkaiser

Thank you for the heads-up regarding #7123. I appreciate the guidance to avoid spending effort on code that will soon be deprecated.

I will pause my work on the current P2300 bulk adapter and follow the progress of #7123 closely. Once that is merged, I’ll re-evaluate how to implement the bulk functionality within the new framework.

In the meantime, I’ll focus on finishing the review items for PR #7070 (local convenience header) and cleaning up any remaining issues on my other active PRs that are unaffected by the sender/receiver removal.

hkaiser · 2026-05-05T19:56:04Z

+            HPX_NO_UNIQUE_ADDRESS std::decay_t<Shape> shape_;
+            HPX_NO_UNIQUE_ADDRESS std::decay_t<F> f_;
+
+#if defined(HPX_HAVE_STDEXEC)


Please remove the case !defined(HPX_HAVE_STDEXEC) as we have dropped our own implementation of senders&receivers.

#if defined(HPX_HAVE_STDEXEC) can be removed now as well.

hkaiser · 2026-05-05T19:56:31Z


 #include <hpx/config.hpp>
 #include <hpx/assert.hpp>
+#include <hpx/execution/queries/get_scheduler.hpp>


This file does not exist anymore. Please adapt.

hkaiser · 2026-05-05T19:57:32Z

 #include <hpx/executors/detail/index_queue_spawning.hpp>
 #include <hpx/executors/execution_policy_mappings.hpp>
+#include <hpx/executors/executor_scheduler.hpp>
+#include <hpx/executors/executor_scheduler_bulk.hpp>


Can we get away without pulling this into the executor file? Would forward declaring some of the stdexec types be sufficient?

I think you can rmeove these files now as you have added the forwarding declaration.

hkaiser · 2026-05-05T19:58:35Z

 #include <hpx/config.hpp>
 #include <hpx/executors/execution_policy_mappings.hpp>
+#include <hpx/executors/executor_scheduler.hpp>
+#include <hpx/executors/executor_scheduler_bulk.hpp>


Same here: can avoid pulling in the stdexec types here?

shivansh023023 · 2026-05-06T21:15:13Z

Hi @hkaiser

Thank you for the feedback. I have refactored the PR to align with the latest stdexec changes:

Purged Legacy Code: Removed all !defined(HPX_HAVE_STDEXEC) blocks from executor_scheduler_bulk.hpp.

Header Optimization: Removed the inclusions of executor_scheduler.hpp and executor_scheduler_bulk.hpp from the parallel_executor and sequenced_executor headers.

Forward Declarations: Implemented forward declarations for the returned scheduler types in the executor headers to prevent bloat.

Fixed Includes: Removed the reference to the deprecated get_scheduler.hpp header.

The headers are now much cleaner. Let me know if there are any other areas you'd like me to slim down!

hkaiser · 2026-05-06T21:55:37Z

+namespace hpx::execution::experimental {
+    template <typename Executor>
+    struct executor_scheduler;
+}


May I suggest to create a forwarding header where this type is declared? This would avoid having the declaration copied all over the place.

charan-003

nice work!!!

charan-003

nice work!!!

- Integrated hpx::execution::experimental::bulk with internal bulk_sync_execute - Implemented robust tag_invoke(connect_t) with full const-correctness - Fixed receiver reference collapsing using std::decay_t - Added executor_algorithm_bulk unit tests for parallel and sequenced execution

…nder/receiver concepts, NVCC guard, dedup get_scheduler, fix post() UB, use get_scheduler in tests

shivansh023023 · 2026-05-07T07:00:03Z

Hi @hkaiser

Thank you for the architectural guidance! I have implemented your suggestions to clean up the header dependencies and tag_invoke logic:

Forwarding Header: I created executor_scheduler_fwd.hpp and moved the declarations there, which allowed me to strip the redundant forward declarations from the individual executor headers.

Tag-Invoke Overloads: I removed the default template arguments and duplicate overloads in parallel_executor and sequenced_executor, replacing them with the concrete friend functions you suggested.

NVCC Fix: I ensured the NVCC/CUDACC guards for the destructors were correctly restored.

Standard Test Patterns: I updated the unit tests to use the standard ex::get_scheduler(exec) call instead of manual constructor calls.

The structure feels much more consistent with the rest of the HPX core modules now. Thanks!

shivansh023023 · 2026-05-07T07:00:30Z

Hi @charan-003

Thanks for the catch on the stdexec compliance and the safety issues! I’ve updated the implementation as follows:

Sender/Receiver Concepts: I added sender_concept to executor_sender and receiver_concept to executor_bulk_receiver. These are now correctly picked up by the stdexec concept checks.

UB Fix in post: I refactored the lambda capture in executor_operation_state::start(). It now captures the state by reference and only moves the receiver inside the task body. This ensures that if hpx::parallel::execution::post throws, the receiver is still valid for the set_error call in the catch block.

I really appreciate the eye for detail on that potential move-before-post UB,definitely a safer implementation now!

…rm_completion_signatures

hkaiser · 2026-05-07T22:55:25Z

+            HPX_NO_UNIQUE_ADDRESS std::decay_t<Shape> shape_;
+            HPX_NO_UNIQUE_ADDRESS std::decay_t<F> f_;
+
+#if defined(HPX_HAVE_STDEXEC)


#if defined(HPX_HAVE_STDEXEC) can be removed now as well.

hkaiser · 2026-05-07T22:56:11Z

 #include <hpx/executors/detail/index_queue_spawning.hpp>
 #include <hpx/executors/execution_policy_mappings.hpp>
+#include <hpx/executors/executor_scheduler.hpp>
+#include <hpx/executors/executor_scheduler_bulk.hpp>


I think you can rmeove these files now as you have added the forwarding declaration.

…cutor includes

shivansh023023 · 2026-05-08T12:51:01Z

@hkaiser
I have just pushed the latest updates for PR #7240, and I’m happy to report that all CI checks are passing! I’ve implemented your latest suggestions to fully modernize the implementation:

C++20 Concepts: I’ve replaced the legacy std::enable_if_t in the executor_scheduler constructor with a clean C++20 requires clause and included the header.

Purged Redundant Guards: Removed the #if defined(HPX_HAVE_STDEXEC) guards in executor_scheduler_bulk.hpp, as we now rely strictly on the modern Sender/Receiver path.

Header Optimization: I have completely removed the implementation headers (executor_scheduler.hpp and executor_scheduler_bulk.hpp) from parallel_executor.hpp and sequenced_executor.hpp. These files now rely solely on the lightweight executor_scheduler_fwd.hpp header, significantly reducing the include bloat for the core executors.

The code is now much cleaner and follows the forwarding pattern we discussed. It should be ready for a final review!

hkaiser · 2026-05-08T13:52:43Z

@shivansh023023 Thanks for the updates. I'd like to wait for #7257 to be finalized before merging anything else related to s&r. Please be patient as this may take a moment.

shivansh023023 · 2026-05-08T13:55:48Z

@shivansh023023 Thanks for the updates. I'd like to wait for #7257 to be finalized before merging anything else related to s&r. Please be patient as this may take a moment.

Sure sir

shivansh023023 requested a review from hkaiser as a code owner May 2, 2026 17:39

shivansh023023 force-pushed the feat/p2300-bulk-integration branch from 5cdcfbd to 7b3fc5f Compare May 2, 2026 17:50

hkaiser added category: senders/receivers Implementations of the p0443r14 / p2300 + p1897 proposals type: enhancement type: compatibility issue labels May 3, 2026

hkaiser reviewed May 5, 2026

View reviewed changes

hkaiser mentioned this pull request May 5, 2026

Implement P2300 get_scheduler bridge for executors #7238

Open

3 tasks

shivansh023023 force-pushed the feat/p2300-bulk-integration branch from 7b3fc5f to 70c4501 Compare May 6, 2026 21:14

hkaiser reviewed May 6, 2026

View reviewed changes

charan-003 reviewed May 6, 2026

View reviewed changes

Comment thread libs/core/executors/include/hpx/executors/executor_scheduler.hpp

Comment thread libs/core/executors/include/hpx/executors/executor_scheduler_bulk.hpp

charan-003 reviewed May 6, 2026

View reviewed changes

Comment thread libs/core/executors/include/hpx/executors/executor_scheduler.hpp Outdated

Hackathon User added 2 commits May 7, 2026 11:54

Address maintainer feedback for PR TheHPXProject#7240: fwd header, se…

1f4aeee

…nder/receiver concepts, NVCC guard, dedup get_scheduler, fix post() UB, use get_scheduler in tests

shivansh023023 force-pushed the feat/p2300-bulk-integration branch from bbfc7db to 1f4aeee Compare May 7, 2026 06:35

Fix formatting

ec7401f

Hackathon User added 3 commits May 7, 2026 14:57

Migrate from deprecated transform_completion_signatures_of to transfo…

13e2e82

…rm_completion_signatures

Fix clang-cl syntax error by moving pragmas outside template declaration

c166077

Fix formatting with clang-format

812850e

hkaiser reviewed May 7, 2026

View reviewed changes

Modernize PR 7240: Use C++20 requires clause and remove redundant exe…

7ab5571

…cutor includes

shivansh023023 force-pushed the feat/p2300-bulk-integration branch from d0b7f07 to 7ab5571 Compare May 8, 2026 07:39

Uh oh!

Conversation

shivansh023023 commented May 2, 2026

P2300 bulk Integration for HPX Executors

Description

Key Technical Improvements:

Proposed Changes

Background context

Checklist

Uh oh!

StellarBot commented May 2, 2026

Uh oh!

codacy-production Bot commented May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Up to standards ✅

Uh oh!

hkaiser commented May 3, 2026

Uh oh!

shivansh023023 commented May 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shivansh023023 commented May 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

charan-003 left a comment

Choose a reason for hiding this comment

Uh oh!

charan-003 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

shivansh023023 commented May 7, 2026

Uh oh!

shivansh023023 commented May 7, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shivansh023023 commented May 8, 2026

Uh oh!

hkaiser commented May 8, 2026

Uh oh!

shivansh023023 commented May 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

P2300 `bulk` Integration for HPX Executors

codacy-production Bot commented May 2, 2026 •

edited

Loading