The BOOST_ASIO_HANDLER_LOCATION((file_name, line, function_name)) macro
may be used to inform the handler tracking mechanism of a source
location. This macro declares an object that is placed on the stack.
When an asynchronous operation is launched with location information, it
outputs lines using the <action> 'n^m', prior to the 'n*m' line that
signifies the beginning of the asynchronous operation. For example:
@asio|1589423304.861944|>7|ec=system:0,bytes_transferred=5
@asio|1589423304.861952|7^8|in 'async_write' (./../../../include/asio/impl/write.hpp:330)
@asio|1589423304.861952|7^8|called from 'do_write' (handler_tracking/async_tcp_echo_server.cpp:62)
@asio|1589423304.861952|7^8|called from 'operator()' (handler_tracking/async_tcp_echo_server.cpp:51)
@asio|1589423304.861952|7*8|socket@0x7ff61c008230.async_send
@asio|1589423304.861975|.8|non_blocking_send,ec=system:0,bytes_transferred=5
@asio|1589423304.861980|<7|
If std::source_location or std::experimental::source_location are
available, the use_awaitable_t token (when default-constructed or used
as a default completion token) will also cause handler tracking to
output a source location for each newly created asynchronous operation.
A use_awaitable_t object may also be explicitly constructed with location
information.
On some versions of Windows, it seems that "self pipe trick" sockets may
be disconnected after a system sleep. To work around this, we recreate
the sockets following an error on read.
The ssl::host_name_verification class is a drop-in replacement for
ssl::rfc2818_verification, which it supersedes. The
ssl::rfc2818_verification class has been marked as deprecated.
Thanks to Arvid Norberg for providing the implementation.
When synchronously or asynchronously accepting a new connection, but
without specifying an executor or execution context, the accept
operation will now correctly propagate the executor type from the
acceptor to the socket. For example, if your acceptor type is:
basic_socket_acceptor<ip::tcp, my_executor_type>
then your accepted socket type will be:
basic_stream_socket<ip::tcp, my_executor_type>
Every I/O executor type now has an associated default completion token
type. This is specified via the `default_completion_token_type` trait.
This trait may be used in asynchronous operation declarations as
follows:
template <
typename IoObject,
typename CompletionToken =
typename default_completion_token_type<
typename IoObject::executor_type
>::type
>
auto async_foo(
IoObject& io_object,
CompletionToken&& token =
typename default_completion_token_type<
typename IoObject::executor_type
>::type{}
);
If not specialised, this trait type is `void`, meaning no default
completion token type is available for the given I/O executor.
The `default_completion_token_type` trait is specialised for the
`use_awaitable` completion token so that it may be used as shown in the
following example:
auto socket = use_awaitable.as_default_on(tcp::socket(my_context));
// ...
co_await socket.async_connect(my_endpoint); // Defaults to use_awaitable.
In this example, type of the `socket` object is transformed from
`tcp::socket` to have an I/O executor with the default completion token
set to `use_awaitable`.
Alternatively, the socket type may be computed directly:
using tcp_socket = use_awaitable_t<>::as_default_on_t<tcp::socket>;
tcp_socket socket(my_context);
// ...
co_await socket.async_connect(my_endpoint); // Defaults to use_awaitable.
The asynchronous operations' initiation function objects now report
their associated I/O executor via the nested type `executor_type` and
member function `get_executor()`.
The presence of `executor_type` and `get_executor()` should be treated
as optional, and consequently it may be preferable to access them via
the `associated_executor` trait and the `get_associated_executor()`
helper function.
The I/O objects provided by Asio now support the nested template type
`rebind_executor` as a way to generically rebind them to an alternative
I/O executor type. For example:
using my_socket_type =
tcp::socket::rebind_executor<my_executor_type>::other;
This change introduces three new concepts:
* completion_signature<T>: Checks if T is a signature of the form R(Args...).
* completion_handler_for<T, Signature>: Checks if T is usable as a completion
handler with the specified signature.
* completion_token_for<T, Signature>: Checks if T is a completion token that
can be used with async_initiate and the specified signature.
For backward compatibility, use the macros BOOST_ASIO_COMPLETION_SIGNATURE,
BOOST_ASIO_COMPLETION_HANDLER_FOR, and BOOST_ASIO_COMPLETION_TOKEN_FOR
respectively. These macros expand to `typename` when concepts are unsupported.
C++14 or later is required to support completion tokens that use
per-operation return type deduction. For C++11 or earlier, a completion
token's async_result specialisation must still provide the nested
typedef `return_type`.
