NVIDIA / NVIDIA/stdexec

Splitting the return value of type pair into two different senders

Open
#479 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C++
Stars
2.4k
Forks
270
Avg merge
3d 6h
Merged PRs (30d)
39

Description

Hello, I am a grad student at Georgia Tech and I have been trying to follow your work on this proposal closely. I am quite looking forward to this proposal going into the C++ standard someday. My question is as follows:

Let's say we have a sender that returns a pair of values std::pair<std::vector, std::set>
Since these objects can be quite costly to copy, I want to move them. But let's say they are computed by a single sender and I want to move these into two different senders creating a split in the dependency chain.

A
| \
B C

So, above the A sender returns the pair and I want the contents of the pair moved to senders B and C. In the proposal, one can use the split() to achieve this kind of split in the dependency DAG but I don't see how I can avoid copying the pair when I create a multishot sender so that both B and C get access to the pair. But, as you can see, this doesn't achieve what I want. I want to move the first of the pair to B and the second of the pair to C.

Is there a way to achieve this kind of functionality with the current status of the proposal?

Thanks,
Fatih

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with issue #479 and the proposal's split() semantics described there. Determine whether the current sender model supports moving the two elements of one pair into separate downstream senders without copying, and document the supported approach or the missing design needed. No source files or tests are named in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.