The any_executor class stores the state of the target's blocking
property to enable an optimisation in any_executor::execute(), i.e. if
the target executor has the property blocking.always, we can avoid a
memory allocation when type-erasing the submitted function object. With
this change the any_executor now "stores" the blocking property as a
different target function table, rather than as a separate member of
type blocking_t. This reduces the size of an any_executor by 8 bytes on
x86-64.
When using standard executors, work is tracked by requiring (or
preferring) an executor with the execution::outstanding_work.tracked
property. This replaces executor_work_guard and make_work_guard() with
code of the form
asio::io_context io_context;
auto work = asio::require(io_context.get_executor(),
asio::execution::outstanding_work.tracked);
To explicitly reset work, store the returned work-tracking executor in
an any_io_executor object:
asio::any_io_executor work
= asio::require(io_context.get_executor(),
asio::execution::outstanding_work.tracked);
and then assign an empty executor into the object when done:
work = asio::any_io_executor();
The asio::any_io_executor type alias has been added as the default
runtime-polymorphic executor for all I/O objects. This type alias points
to the execution::any_executor<> template with a set of supportable
properties specified for use with I/O.
If required for backward compatibility, BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT
can be defined. This changes the asio::any_io_executor type alias to
point to the Networking TS-based runtime-polymorphic asio::executor
class instead.
The detail::io_object_executor wrapper has been removed, and the job of
detecting, and optimising for, native I/O executors is now performed
directly in the detail::handler_work implementation.
When we can determine at compile time that the user has supplied a
single buffer, use read/write rather than readv/writev, as the former
system calls can be faster.
When we can determine at compile time that the user has supplied a
single buffer, use recvfrom/sendto rather than recvmsg/sendmsg, as the
former system calls can be faster.
