Difference between revisions of "cpp/execution"
From cppreference.com
< cpp
Line 4: | Line 4: | ||
{{fmbox|class=noprint|style=font-size: 0.8em|text='''Note''' This is a planned '''extention''' to the <execution> {{mark c++17}} header;}} | {{fmbox|class=noprint|style=font-size: 0.8em|text='''Note''' This is a planned '''extention''' to the <execution> {{mark c++17}} header;}} | ||
− | {{fmbox|class=noprint|style=font-size: 0.8em|text='''Draft''' The functionality described on this page is a draft, based on the latest revision of P2300 | + | {{fmbox|class=noprint|style=font-size: 0.8em|text='''Draft''' The functionality described on this page is a draft, based on the latest revision of P2300, targeting {{mark c++26}};}} |
Revision as of 03:04, 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.)
Library Utilities
Sender Factories
A 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; }