diff options
Diffstat (limited to '3rdparty/asio/src/doc/overview/async.qbk')
-rw-r--r-- | 3rdparty/asio/src/doc/overview/async.qbk | 185 |
1 files changed, 0 insertions, 185 deletions
diff --git a/3rdparty/asio/src/doc/overview/async.qbk b/3rdparty/asio/src/doc/overview/async.qbk deleted file mode 100644 index ff627872416..00000000000 --- a/3rdparty/asio/src/doc/overview/async.qbk +++ /dev/null @@ -1,185 +0,0 @@ -[/ - / Copyright (c) 2003-2016 Christopher M. Kohlhoff (chris at kohlhoff dot com) - / - / Distributed under the Boost Software License, Version 1.0. (See accompanying - / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) - /] - -[section:async The Proactor Design Pattern: Concurrency Without Threads] - -The Asio library offers side-by-side support for synchronous and asynchronous -operations. The asynchronous support is based on the Proactor design pattern -[link asio.overview.core.async.references \[POSA2\]]. The advantages and -disadvantages of this approach, when compared to a synchronous-only or Reactor -approach, are outlined below. - -[heading Proactor and Asio] - -Let us examine how the Proactor design pattern is implemented in Asio, -without reference to platform-specific details. - -[$proactor.png] - -[*Proactor design pattern (adapted from \[POSA2\])] - -[mdash] Asynchronous Operation - -[:Defines an operation that is executed asynchronously, such as an asynchronous -read or write on a socket.] - -[mdash] Asynchronous Operation Processor - -[:Executes asynchronous operations and queues events on a completion event -queue when operations complete. From a high-level point of view, internal -services like `reactive_socket_service` are asynchronous operation processors.] - -[mdash] Completion Event Queue - -[:Buffers completion events until they are dequeued by an asynchronous event -demultiplexer.] - -[mdash] Completion Handler - -[:Processes the result of an asynchronous operation. These are function -objects, often created using `boost::bind`.] - -[mdash] Asynchronous Event Demultiplexer - -[:Blocks waiting for events to occur on the completion event queue, and returns -a completed event to its caller.] - -[mdash] Proactor - -[:Calls the asynchronous event demultiplexer to dequeue events, and dispatches -the completion handler (i.e. invokes the function object) associated with the -event. This abstraction is represented by the `io_context` class.] - -[mdash] Initiator - -[:Application-specific code that starts asynchronous operations. The initiator -interacts with an asynchronous operation processor via a high-level interface -such as `basic_stream_socket`, which in turn delegates to a service like -`reactive_socket_service`.] - -[heading Implementation Using Reactor] - -On many platforms, Asio implements the Proactor design pattern in terms -of a Reactor, such as `select`, `epoll` or `kqueue`. This implementation -approach corresponds to the Proactor design pattern as follows: - -[mdash] Asynchronous Operation Processor - -[:A reactor implemented using `select`, `epoll` or `kqueue`. When the reactor -indicates that the resource is ready to perform the operation, the processor -executes the asynchronous operation and enqueues the associated completion -handler on the completion event queue.] - -[mdash] Completion Event Queue - -[:A linked list of completion handlers (i.e. function objects).] - -[mdash] Asynchronous Event Demultiplexer - -[:This is implemented by waiting on an event or condition variable until a -completion handler is available in the completion event queue.] - -[heading Implementation Using Windows Overlapped I/O] - -On Windows NT, 2000 and XP, Asio takes advantage of overlapped I/O to -provide an efficient implementation of the Proactor design pattern. This -implementation approach corresponds to the Proactor design pattern as follows: - -[mdash] Asynchronous Operation Processor - -[:This is implemented by the operating system. Operations are initiated by -calling an overlapped function such as `AcceptEx`.] - -[mdash] Completion Event Queue - -[:This is implemented by the operating system, and is associated with an I/O -completion port. There is one I/O completion port for each `io_context` -instance.] - -[mdash] Asynchronous Event Demultiplexer - -[:Called by Asio to dequeue events and their associated completion -handlers.] - -[heading Advantages] - -[mdash] Portability. - -[:Many operating systems offer a native asynchronous I/O API (such as -overlapped I/O on __Windows__) as the preferred option for developing high -performance network applications. The library may be implemented in terms of -native asynchronous I/O. However, if native support is not available, the -library may also be implemented using synchronous event demultiplexors that -typify the Reactor pattern, such as __POSIX__ `select()`.] - -[mdash] Decoupling threading from concurrency. - -[:Long-duration operations are performed asynchronously by the implementation -on behalf of the application. Consequently applications do not need to spawn -many threads in order to increase concurrency.] - -[mdash] Performance and scalability. - -[:Implementation strategies such as thread-per-connection (which a -synchronous-only approach would require) can degrade system performance, due to -increased context switching, synchronisation and data movement among CPUs. With -asynchronous operations it is possible to avoid the cost of context switching -by minimising the number of operating system threads [mdash] typically a -limited resource [mdash] and only activating the logical threads of control -that have events to process.] - -[mdash] Simplified application synchronisation. - -[:Asynchronous operation completion handlers can be written as though they -exist in a single-threaded environment, and so application logic can be -developed with little or no concern for synchronisation issues.] - -[mdash] Function composition. - -[:Function composition refers to the implementation of functions to provide a -higher-level operation, such as sending a message in a particular format. Each -function is implemented in terms of multiple calls to lower-level read or write -operations.] - -[:For example, consider a protocol where each message consists of a -fixed-length header followed by a variable length body, where the length of the -body is specified in the header. A hypothetical read_message operation could be -implemented using two lower-level reads, the first to receive the header and, -once the length is known, the second to receive the body.] - -[:To compose functions in an asynchronous model, asynchronous operations can be -chained together. That is, a completion handler for one operation can initiate -the next. Starting the first call in the chain can be encapsulated so that the -caller need not be aware that the higher-level operation is implemented as a -chain of asynchronous operations.] - -[:The ability to compose new operations in this way simplifies the development -of higher levels of abstraction above a networking library, such as functions -to support a specific protocol.] - -[heading Disadvantages] - -[mdash] Program complexity. - -[:It is more difficult to develop applications using asynchronous mechanisms -due to the separation in time and space between operation initiation and -completion. Applications may also be harder to debug due to the inverted flow -of control.] - -[mdash] Memory usage. - -[:Buffer space must be committed for the duration of a read or write operation, -which may continue indefinitely, and a separate buffer is required for each -concurrent operation. The Reactor pattern, on the other hand, does not require -buffer space until a socket is ready for reading or writing.] - -[heading References] - -\[POSA2\] D. Schmidt et al, ['Pattern Oriented Software Architecture, Volume -2]. Wiley, 2000. - -[endsect] |