Difference between revisions of "cpp/execution"
From cppreference.com
< cpp
| Line 22: | Line 22: | ||
* '''Scheduler''' - Execution context on which operation can run (CPU, thread pool, GPU threads, Event loop, etc.) | * '''Scheduler''' - Execution context on which operation can run (CPU, thread pool, GPU threads, Event loop, etc.) | ||
| − | === | + | ===Senders=== |
====Sender Factories==== | ====Sender Factories==== | ||
| − | A factory takes a non-sender (function/data) and returns a sender. | + | A sender factory takes a non-sender (function/data) and returns a sender. |
A sender with no completion schedulers is an “open-ended” operation, that can be used in the pipe. | A sender with no completion schedulers is an “open-ended” operation, that can be used in the pipe. | ||
All the following senders are created without a completion scheduler. | All the following senders are created without a completion scheduler. | ||
| − | |||
{{dsc begin}} | {{dsc begin}} | ||
| Line 41: | Line 40: | ||
{{dsc inc|cpp/execution/dsc read}} | {{dsc inc|cpp/execution/dsc read}} | ||
{{dsc end}} | {{dsc end}} | ||
| − | |||
Revision as of 12:57, 24 January 2024
The Execution library suggests a framework for managing asynchronous execution on generic execution resources, targeting the standard C++ library.
The library aims to provide vocabulary types for async operations and to allow the construction of tasks execution graphs in a simple, composable way.
Contents |
Library-wide definitions
- Sender - Contains data and/or work to be sent for execution.
- Senders can be chained to build execution pipes (translated into a task graph).
- Different types of senders can be produced by senders factories/adaptors.
- Receiver/Sender Consumer - Closure of execution pipe, consume sender(s) and returns an Operation State.
- Receiver contains environment, which holds data on the execution context
- By default (if not provided) the environment is the default env.
- Operation State - Object which holds: data + work + execution context. Execution by calling “state”
- Scheduler - Execution context on which operation can run (CPU, thread pool, GPU threads, Event loop, etc.)
Senders
Sender Factories
A sender factory takes a non-sender (function/data) and returns a sender.
A sender with no completion schedulers is an “open-ended” operation, that can be used in the pipe. All the following senders are created without a completion scheduler.
| Defined in header
<execution> | |
| Defined in namespace
std::execution | |
| (C++26) |
prepares a task graph for execution on a given scheduler (customization point object) |
| (C++26) |
Accepts a variadic number of arguments and returns a sender that, when connected and started, completes synchronously by passing the arguments to the receiver's value completion function (customization point object) |
| (C++26) |
Accepts a single argument and returns a sender that, when connected and started, completes synchronously by passing the argument to the receiver's error completion function (customization point object) |
| (C++26) |
creates a sender that completes immediately by calling its receiver's set_stopped(customization point object) |
Example
Note: the example is using stdexec (available on godbolt), which is an experimental reference implementation for "std::execution".
Run this code
#include <thread> #include <iostream> #include <stdexec/execution.hpp> using namespace std::literals; stdexec::run_loop loop; std::thread worker([]{ loop.run(); }); int main() { auto hello = stdexec::just("hello world"s); auto work = hello | stdexec::then( [](auto msg) { std::cout << msg << '\n'; return 0; }); auto [result] = stdexec::sync_wait(stdexec::on(loop.get_scheduler(), std::move(work))).value(); loop.finish(); worker.join(); return result; }
