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:54:30Z

+        template <typename Exec,
+            typename = std::enable_if_t<
+                !std::is_same_v<std::decay_t<Exec>, executor_scheduler>>>
+        explicit executor_scheduler(Exec&& exec)


Let's use concepts, wherever possible:

Suggested change

template <typename Exec,

typename = std::enable_if_t<

!std::is_same_v<std::decay_t<Exec>, executor_scheduler>>>

explicit executor_scheduler(Exec&& exec)

template <typename Exec>

requires(!std::isame_as<std::decay_t<Exec>, executor_scheduler>)

explicit executor_scheduler(Exec&& exec)

You may have to add #include <concepts> in this case.

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 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!

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!

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