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);
This change adds limited support for using Asio with the Windows
Runtime. It requires that the language extensions be enabled. Due to the
restricted facilities exposed by the Windows Runtime API, the port comes
with the following caveats:
* The core facilities such as the io_service, strand, buffers, composed
operations, timers, etc., should all work as normal.
* For sockets, only client-side TCP is supported.
* Explicit binding of a client-side TCP socket is not supported.
* The cancel() function is not supported for sockets. Asynchronous
operations may only be cancelled by closing the socket.
* Operations that use null_buffers are not supported.
* Only tcp::no_delay and socket_base::keep_alive options are supported.
* Resolvers do not support service names, only numbers. I.e. you must
use 80 rather than http.
* Most resolver query flags have no effect.
[SVN r85764]
Christopher Kohlhoff