Added new overloads of experimental::make_parallel_group that may be used
to launch a dynamically-sized set of asynchronous operations, where all
operations are the same type. For example:
using op_type = decltype(
socket1.async_read_some(
boost::asio::buffer(data1),
boost::asio::deferred
)
);
std::vector<op_type> ops;
ops.push_back(
socket1.async_read_some(
boost::asio::buffer(data1),
boost::asio::deferred
)
);
ops.push_back(
socket2.async_read_some(
boost::asio::buffer(data2),
boost::asio::deferred
)
);
boost::asio::experimental::make_parallel_group(ops).async_wait(
boost::asio::experimental::wait_for_all(),
[](
std::vector<std::size_t> completion_order,
std::vector<boost::system::error_code> e,
std::vector<std::size_t> n
)
{
for (std::size_t i = 0; i < completion_order.size(); ++i)
{
std::size_t idx = completion_order[i];
std::cout << "socket " << idx << " finished: ";
std::cout << e[idx] << ", " << n[idx] << "\n";
}
}
);
Thanks go to Klemens Morgenstern for supplying part of this implementation.
Added new spawn() overloads that conform to the requirements for
asynchronous operations. These overloads also support cancellation. When
targeting C++11 and later these functions are implemented in terms of
Boost.Context directly.
The existing overloads have been retained but are deprecated.
This is no longer an experimental facility. The names deferred and
deferred_t have been temporarily retained as deprecated entities under
the asio::experimental namespace, for backwards compatibility.
This change adds support for stream-oriented and random-access files.
For example, to write to a newly created stream-oriented file:
asio::stream_file file(
my_io_context, "/path/to/file",
asio::stream_file::write_only
| asio::stream_file::create
| asio::stream_file::truncate);
file.async_write_some(my_buffer,
[](error_code e, size_t n)
{
// ...
});
or to read from a random-access file:
asio::random_access_file file(
my_io_context, "/path/to/file",
asio::random_access_file::read_only);
file.async_read_some_at(1234, my_buffer,
[](error_code e, size_t n)
{
// ...
});
This feature currently supports I/O completion ports on Windows, and
io_uring on Linux (define BOOST_ASIO_HAS_IO_URING to enable).
Rather than using a context() member function, query the executor's
execution::context_t property to obtain its associated execution
context:
asio::execution_context& context
= asio::query(my_io_executor, asio::execution::context);
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 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.
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);
Christopher Kohlhoff