Skip to content

Provide a more precise definition for get_completion_scheduler than present in the user-facing design section #1

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
LeeHowes opened this issue May 12, 2021 · 3 comments
Milestone

Comments

@LeeHowes
Copy link
Contributor

Give precise definition. Maybe:
if the sender completes with set_value, it will call set_value on the returned scheduler.

@griwes
Copy link
Collaborator

griwes commented May 19, 2021

The precise definition will go into the wording, and possibly into the implementer-centric design section somewhere. The user-side design section does not talk about receivers in the first place, so it cannot mention set_value.

@griwes griwes changed the title get_underlying_scheduler -> get_completion_scheduler Provide a more precise definition for get_completion_scheduler than present in the user-facing design section May 19, 2021
@griwes
Copy link
Collaborator

griwes commented May 19, 2021

Rename has been done, updating the title to track the remainder of this issue.

griwes added a commit that referenced this issue Jun 5, 2021
@griwes
Copy link
Collaborator

griwes commented Jun 12, 2021

The specification now has wording that states that if this is not true, the behavior is undefined.

@griwes griwes closed this as completed Jun 12, 2021
@brycelelbach brycelelbach added this to the R2 milestone Jun 29, 2021
gevtushenko added a commit that referenced this issue Feb 11, 2022
Slightly reduce register pressure and compiler optimization options
ericniebler pushed a commit that referenced this issue Jan 19, 2023
attemted cmake fix for nvhpc compiler
ericniebler pushed a commit to ericniebler/stdexec that referenced this issue Sep 18, 2023
fix cycle in type system in stream scheduler concepts
copy-pr-bot bot pushed a commit that referenced this issue Jan 4, 2024
lucteo referenced this issue in lucteo/stdexec Jan 14, 2024
* Type erasing set calls

* Full interface type erased

* Fixed RVO of operation state

* Resiliance and bug fixes
DavidElesTheFox pushed a commit to DavidElesTheFox/stdexec that referenced this issue Jan 8, 2025
When stdexec is used as a 3rd-party dependency for example with fetch
content it is downloaded into the cmake build folder under the _deps.

A setup like that will results a build directory structure like
build/_deps/stdexec-src
           /stdexec-build

in this context the CMAKE_BINARY_DIR is the build folder and the
CMAKE_CURRENT_BINARY_DIR is the build/_deps/stdexec-build.

Issue NVIDIA#1:
Right now the build will place two files into the 'main' build folder:
 - execution.bs
 - RAPIDS.cmake

It might causes problems when the main cmake project uses RAPIDS
with a different version.

Issue NVIDIA#2: There is no such a file stdexec_version_config.hpp under the
main build tree. And it will cause a configuration error.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants