Exit Zen
17
string ID 176
type: heading
English
Asynchronous I/O
16/160 · 16
18
string ID 178
type: paragraph
English
An asynchronous operation begins with a call to an [@boost:/doc/html/boost_asio/reference/asynchronous_operations.html ['initiating function]], which starts the operation and returns to the caller immediately. This ['outstanding] asynchronous operation proceeds concurrently without blocking the caller. When the externally observable side effects are fully established, a movable function object known as a [@boost:/doc/html/boost_asio/reference/CompletionHandler.html ['completion handler]] provided in the initiating function call is queued for execution with the results, which may include the error code and other specific information. An asynchronous operation is said to be ['completed] after the completion handler is queued. The code that follows shows how some text may be written to a socket asynchronously, invoking a lambda when the operation is complete:
868/8680 · 868
19
string ID 196
type: paragraph
English
Every completion handler (also referred to as a [@https://en.wikipedia.org/wiki/Continuation ['continuation]]) has both an [@boost:/doc/html/boost_asio/overview/core/allocation.html ['associated allocator]] returned by [@boost:/doc/html/boost_asio/reference/get_associated_allocator.html `net::get_associated_allocator`], , an [@boost:/doc/html/boost_asio/reference/associated_cancellation_slot.html ['associated cancellation slot]] returned by [@boost:/doc/html/boost_asio/reference/associated_cancellation_slot.html `net::get_associated_cancellation_slot`]. and an [@boost:/doc/html/boost_asio/reference/associated_executor.html ['associated executor]] returned by [@boost:/doc/html/boost_asio/reference/get_associated_executor.html `net::get_associated_executor`]. These associations may be specified intrusively:
816/8160 · 816
20
string ID 214
type: paragraph
English
Or these associations may be specified non-intrusively, by specializing the class templates [@boost:/doc/html/boost_asio/reference/associated_allocator.html `net::associated_allocator`] , [@boost:/doc/html/boost_asio/reference/associated_cancellation_slot.html `net::associated_cancellation_slot`] and [@boost:/doc/html/boost_asio/reference/associated_executor.html `net::associated_executor`]:
394/3940 · 394
21
string ID 224
type: paragraph
English
The function [@boost:/doc/html/boost_asio/reference/bind_executor.html `net::bind_executor`] may be used when the caller wants to change the executor of a completion handler.
174/1740 · 174
22
string ID 229
type: paragraph
English
The allocator is used by the implementation to obtain any temporary storage necessary to perform the operation. Temporary allocations are always freed before the completion handler is invoked. The executor is a cheaply copyable object providing the algorithm used to invoke the completion handler. Unless customized by the caller, a completion handler defaults to using `std::allocator<void>` and the executor of the corresponding I/O object.
442/4420 · 442
23
string ID 236
type: paragraph
English
The function [@boost:/doc/html/boost_asio/reference/bind_allocator.html `net::bind_allocator`] can be used when the caller wants to assign a custom allocator to the operation.
175/1750 · 175
24
string ID 241
type: paragraph
English
A completion token's associated cancellation_slot can be used to cancel single operations. This is often passed through by the completion token such as [@boost:/doc/html/boost_asio/reference/use_awaitable.html `net::use_awaitable`] or [@boost:/doc/html/boost_asio/reference/yield_context.html `net::yield_context`] .
316/3160 · 316
25
string ID 248
type: paragraph
English
The available [@boost:/doc/html/boost_asio/reference/cancellation_type.html cancellation types] are listed below.
113/1130 · 113
26
string ID 250
type: list
English
# `terminal`
12/120 · 12
27
string ID 254
type: list
English
# `partial`
11/110 · 11
28
string ID 259
type: list
English
# `total`
9/100 · 9
29
string ID 266
type: paragraph
English
Networking prescribes facilities to determine the context in which handlers run. Every I/O object refers to an __ExecutionContext__ for obtaining the __Executor__ instance used to invoke completion handlers. An executor determines where and how completion handlers are invoked. Executors obtained from an instance of __io_context__ offer a basic guarantee: handlers will only be invoked from threads which are currently calling [@boost:/doc/html/boost_asio/reference/io_context/run/overload1.html `net::io_context::run`].
521/5210 · 521
30
string ID 274
type: paragraph
English
The __AsyncReadStream__ and __AsyncWriteStream__ concepts define requirements for ['asynchronous streams]: a portable I/O abstraction that exchanges data asynchronously using buffer sequences to represent bytes and `error_code` to report any failures. An ['asynchronous stream algorithm] is written as a templated initiating function template accepting a stream object meeting the named requirements for asynchronous reading, writing, or both. This example shows an algorithm which writes some text to an asynchronous stream:
525/5250 · 525
31
string ID 288
type: heading
English
Concurrency
11/110 · 11
32
string ID 290
type: paragraph
English
I/O objects such as sockets and streams [*are not thread-safe]. Although it is possible to have more than one operation outstanding (for example, a simultaneous asynchronous read and asynchronous write) the stream object itself may only be accessed from one thread at a time. This means that member functions such as move constructors, destructors, or initiating functions must not be called concurrently. Usually this is accomplished with synchronization primitives such as a [@https://en.cppreference.com/w/cpp/thread/mutex `mutex`], but concurrent network programs need a better way to access shared resources, since acquiring ownership of a mutex could block threads from performing uncontended work. For efficiency, networking adopts a model of using threads without explicit locking by requiring all access to I/O objects to be performed within a [@boost:/doc/html/boost_asio/overview/core/strands.html ['strand]].
920/9200 · 920
33
string ID 307
type: heading
English
Universal Model
15/150 · 15
34
string ID 309
type: paragraph
English
Because completion handlers cause an inversion of the flow of control, sometimes other methods of attaching a continuation are desired. Networking provides the [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf ['Universal Model for Asynchronous Operations]], providing a customizable means for transforming the signature of the initiating function to use other types of objects and methods in place of a completion handler callback. For example to call to write a string to a socket asynchronously, using a `std::future` to receive the number of bytes transferred thus looks like this:
603/6030 · 603
35
string ID 321
type: paragraph
English
This functionality is enabled by passing the variable [@boost:/doc/html/boost_asio/reference/use_future.html `net::use_future`] (of type [@boost:/doc/html/boost_asio/reference/use_future_t.html `net::use_future_t<>`]) in place of the completion handler. The same `async_write` function overload can work with a [@https://en.wikipedia.org/wiki/Fiber_(computer_science) ['fiber]] launched with [@boost:/doc/html/boost_asio/reference/spawn/overload1.html `asio::spawn`]:
467/4670 · 467
36
string ID 333
type: paragraph
English
In both of these cases, an object with a specific type is used in place of the completion handler, and the return value of the initiating function is transformed from `void` to `std::future<std::size_t>` or `std::size_t`. The handler is sometimes called a __CompletionToken__ when used in this context. The return type transformation is supported by customization points in the initiating function signature. Here is the signature for [@boost:/doc/html/boost_asio/reference/async_write/overload1.html `net::async_write`]:
521/5210 · 521