futures/future.hpp
Future types.
#include <futures/future.hpp>
Namespaces
| Name | Description |
|---|---|
| futures | Main library namespace. |
Classes
| Classes | Description |
|---|---|
| basic_future | A basic future type with custom features. (class) |
Description
These future types support extensions such as:
- continuations
- stop tokens
- deferred tasks
Many of the ideas for these functions are based on:
- extensions for concurrency (ISO/IEC TS 19571:2016)
- async++
- continuable
- TBB
However, we use concepts and the ASIO proposed standard executors (P0443r13, P1348r0, and P1393r0) to allow for better interoperability with the C++ standard and other future types, such as std::future and boost::future.
A few other relevant differences are:
- the
asyncfunction can accept any executor - the
asyncfunction uses a reasonable dynamic thread pool by default - future-concepts allows new future classes with extensions
- algorithms can be reused with other future types
- a cancellable future class is provided for more sensitive use cases
- the API can be updated as the standard gets updated
- standard parallel algorithms are provided with the executors
This interoperability comes at a price for continuations, as we might need to poll for when_all/when_any/then events, because std::future does not support internal continuations.
A number of heuristics to avoid polling for when_all/when_any/then:
- future-like classes that satisfy the
is_futureconcept can be mixed when_all(oroperator&&) returns awhen_all_futureclass, which does not create a newfutureat all and can check directly if futures are readywhen_any(oroperator||) returns awhen_any_futureclass, which implements a number of heuristics to avoid polling, such as limited polling time, increased pooling intervals, and only launching the necessary continuation futures for long tasks.then(oroperator>>) returns a new future object that sleeps while the previous future isn't ready- when the standard supports that, this approach based on concepts also serve as extension points to allow for these proxy classes to change their behavior to some other algorithm that makes more sense for futures that support continuations, cancellation, progress, and queries.
- the concepts allow for all possible future types to interoperate.
Note that although when_all always takes longer than when_any, when_any involves a number of heuristics that influence its performance.
See Also:
std::experimental::concurrency- https://think-async.com/Asio/asio-1.18.2/doc/asio/std_executors.html
- https://github.com/Amanieu/asyncplusplus
Updated on 2023-01-04