Conservatively prevent the thread_pool's internal locking behaviour from
being changed via the ASIO_CONCURRENCY_HINT_ macros, as there is no way
to use a thread_pool object in a purely single-threaded use case anyway.
This change also fixes a conversion warning.
The awaitable<>, co_spawn(), this_coro, detached, and redirect_error
facilities have been moved from the asio::experimental namespace to
namespace asio. As part of this change, the this_coro::token() awaitable
has been superseded by the asio::use_awaitable completion token.
Please note that the use_awaitable and redirect_error completion tokens
work only with asynchronous operations that use the new form of
async_result with member function initiate(). Furthermore, when using
use_awaitable, please be aware that the asynchronous operation is not
initiated until co_await is applied to the awaitable<>.
The `async_result` template now supports a new form:
template <typename CompletionToken, typename Signature>
struct async_result
{
typedef /* ... */ return_type;
template <typename Initiation,
typename RawCompletionToken,
typename... Args>
static return_type initiate(
Initiation&& initiation,
RawCompletionToken&& token,
Args&&... args);
};
The `initiate()` function must:
* Transform the token into a completion handler object `handler`.
* Cause the invocation of the function object `initiation` as if
by calling:
std::forward<Initiation>(initiation)(
std::move(handler),
std::forward<Args>(args)...);
The invocation of `initiation` may be deferred (e.g. lazily evaluated),
in which case `initiation` and `args` must be decay-copied and moved
as required.
A helper function template `async_initiate` has also been added as a
wrapper for the invocation of `async_result<>::initiate`. For backward
compatibility, this function supports both the old and new async_result
forms.
All I/O objects now have an additional Executor template parameter. This
template parameter defaults to the asio::executor type (the polymorphic
executor wrapper) but can be used to specify a user-defined executor
type.
I/O objects' constructors and functions that previously took an
asio::io_context& now accept either an Executor or a reference to a
concrete ExecutionContext (such as asio::io_context or
asio::thread_pool).
One potential point of breakage in existing user code is when reusing an
I/O object's io_context for constructing another I/O object, as in:
asio::steady_timer my_timer(my_socket.get_executor().context());
To fix this, either construct the second I/O object using the first I/O
object's executor:
asio::steady_timer my_timer(my_socket.get_executor());
or otherwise explicitly pass the io_context:
asio::steady_timer my_timer(my_io_context);
