Skip to content

Pr/cuda pipeline canonical as sender - #389

Merged
sgerbino merged 2 commits into
cppalliance:developfrom
sgerbino:pr/cuda-pipeline-canonical-as-sender
Aug 27, 2026
Merged

Pr/cuda pipeline canonical as sender#389
sgerbino merged 2 commits into
cppalliance:developfrom
sgerbino:pr/cuda-pipeline-canonical-as-sender

Conversation

@sgerbino

Copy link
Copy Markdown
Collaborator

No description provided.

cuda/pipeline carried a copy of bench/stdexec's awaitable_sender.hpp,
which splits a compound io_result at runtime into set_value(n) or
set_error(ec). The canonical bridge in example/awaitable-sender
rejects such awaitables at compile time because exclusive completion
channels would drop a partial read's byte count. The tree therefore
had two as_sender definitions that disagreed on the paper's central
question.

Include the canonical header instead and rewrite scene 2 around the
sanctioned route: a task<error_code> wrapper (read_into) that moves the
byte count out through a side channel and hands the bridge only the
error code. Both scene 2 paths still run; the error path shows the
count reaching the caller while upon_error sees the error. The
await_sender direction keeps its local stdexec copy, since the
canonical sender-bridge copy targets beman.execution.
The bench copies of the awaitable-to-sender bridge accept a compound
io_result and split it at runtime, dropping the byte count that
accompanies an error. The canonical as_sender in
example/awaitable-sender rejects that at compile time. Two functions
with one name and opposite contracts invite copying the wrong one, as
cuda/pipeline did.

Name the benchmark bridges as_sender_lossy and say why they exist:
they measure the bridge without the task<error_code> wrapper the
canonical bridge requires. No behavior change.
@cppalliance-bot

Copy link
Copy Markdown

An automated preview of the documentation is available at https://389.capy.prtest3.cppalliance.org/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2026-08-27 15:33:23 UTC

@cppalliance-bot

Copy link
Copy Markdown

GCOVR code coverage report https://389.capy.prtest3.cppalliance.org/gcovr/index.html
LCOV code coverage report https://389.capy.prtest3.cppalliance.org/genhtml/index.html
Coverage Diff Report https://389.capy.prtest3.cppalliance.org/diff-report/index.html

Build time: 2026-08-27 15:44:46 UTC

@codecov

codecov Bot commented Aug 27, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.09%. Comparing base (cace302) to head (34d1046).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff            @@
##           develop     #389   +/-   ##
========================================
  Coverage    98.09%   98.09%           
========================================
  Files          130      130           
  Lines         6291     6291           
========================================
  Hits          6171     6171           
  Misses         120      120           
Flag Coverage Δ
linux 98.08% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 4 files with indirect coverage changes


Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cace302...34d1046. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@sgerbino
sgerbino merged commit 93e011f into cppalliance:develop Aug 27, 2026
38 checks passed
@sgerbino
sgerbino deleted the pr/cuda-pipeline-canonical-as-sender branch August 27, 2026 16:03
@github-project-automation github-project-automation Bot moved this from Backlog to Done in Beast2 Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants