diff options
Diffstat (limited to '3rdparty/asio/src/doc/overview')
33 files changed, 0 insertions, 3226 deletions
diff --git a/3rdparty/asio/src/doc/overview/allocation.qbk b/3rdparty/asio/src/doc/overview/allocation.qbk deleted file mode 100644 index ecdc71a5011..00000000000 --- a/3rdparty/asio/src/doc/overview/allocation.qbk +++ /dev/null @@ -1,58 +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:allocation Custom Memory Allocation] - -Many asynchronous operations need to allocate an object to store state -associated with the operation. For example, a Win32 implementation needs -`OVERLAPPED`-derived objects to pass to Win32 API functions. - -Furthermore, programs typically contain easily identifiable chains of -asynchronous operations. A half duplex protocol implementation (e.g. an HTTP -server) would have a single chain of operations per client (receives followed -by sends). A full duplex protocol implementation would have two chains -executing in parallel. Programs should be able to leverage this knowledge to -reuse memory for all asynchronous operations in a chain. - -Given a copy of a user-defined `Handler` object `h`, if the implementation -needs to allocate memory associated with that handler it will execute the code: - - void* pointer = asio_handler_allocate(size, &h); - -Similarly, to deallocate the memory it will execute: - - asio_handler_deallocate(pointer, size, &h); - -These functions are located using argument-dependent lookup. The implementation -provides default implementations of the above functions in the `asio` namespace: - - void* asio_handler_allocate(size_t, ...); - void asio_handler_deallocate(void*, size_t, ...); - -which are implemented in terms of `::operator new()` and `::operator delete()` -respectively. - -The implementation guarantees that the deallocation will occur before the -associated handler is invoked, which means the memory is ready to be reused for -any new asynchronous operations started by the handler. - -The custom memory allocation functions may be called from any user-created -thread that is calling a library function. The implementation guarantees that, -for the asynchronous operations included the library, the implementation will -not make concurrent calls to the memory allocation functions for that handler. -The implementation will insert appropriate memory barriers to ensure correct -memory visibility should allocation functions need to be called from different -threads. - -[heading See Also] - -[link asio.reference.asio_handler_allocate asio_handler_allocate], -[link asio.reference.asio_handler_deallocate asio_handler_deallocate], -[link asio.examples.cpp03_examples.allocation custom memory allocation example (C++03)], -[link asio.examples.cpp11_examples.allocation custom memory allocation example (C++11)]. - -[endsect] 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] diff --git a/3rdparty/asio/src/doc/overview/async_op1.dot b/3rdparty/asio/src/doc/overview/async_op1.dot deleted file mode 100644 index cbb95fb6949..00000000000 --- a/3rdparty/asio/src/doc/overview/async_op1.dot +++ /dev/null @@ -1,78 +0,0 @@ -digraph g -{ - graph - [ - nodesep="0.2" - ]; - - edge - [ - fontname="Helvetica", - fontsize=10, - labelfontname="Helvetica", - labelfontsize=10 - ]; - - node - [ - fontname="Helvetica", - fontsize=10, - shape=box - ]; - - edge - [ - arrowhead="open" - ] - - // Program elements. - { - operating_system [ label="Operating System", shape=ellipse ]; - io_context [ label="io_context" ]; - io_object [ label="I/O Object\ne.g. socket" ]; - your_program [ label="Your Program" ]; - your_completion_handler [ label="Your Completion Handler" ]; - } - - // Owning relationships. - { - edge [ arrowtail="diamond" ]; - your_program:e -> your_completion_handler:n; - your_program:w -> io_object:nw; - your_program:se -> io_context:ne; - } - - // Non-owning relationships; - { - io_object:sw -> io_context:w; - } - - // Visible actions. - { - edge [ style="dashed", color="#808080" ]; - - // Forward actions. - { - your_program:sw -> io_object:n [ label="1" ]; - io_object:s -> io_context:nw [ label="2" ]; - io_context:s -> operating_system:n [ label="3" ]; - } - } - - // Invisible actions. - { - edge [ style="invis" ]; - - // Forward actions. - { - your_program:s -> io_context:n [ label="5" ]; - } - - // Reverse actions. - { - edge [ arrowhead="none", arrowtail="open" ]; - //io_context:s -> operating_system:n [ label="4" ]; - your_completion_handler:s -> io_context:e [ label="6" ]; - } - } -} diff --git a/3rdparty/asio/src/doc/overview/async_op1.png b/3rdparty/asio/src/doc/overview/async_op1.png Binary files differdeleted file mode 100644 index 464bc90e683..00000000000 --- a/3rdparty/asio/src/doc/overview/async_op1.png +++ /dev/null diff --git a/3rdparty/asio/src/doc/overview/async_op2.dot b/3rdparty/asio/src/doc/overview/async_op2.dot deleted file mode 100644 index 60a3275c391..00000000000 --- a/3rdparty/asio/src/doc/overview/async_op2.dot +++ /dev/null @@ -1,78 +0,0 @@ -digraph g -{ - graph - [ - nodesep="0.2" - ]; - - edge - [ - fontname="Helvetica", - fontsize=10, - labelfontname="Helvetica", - labelfontsize=10 - ]; - - node - [ - fontname="Helvetica", - fontsize=10, - shape=box - ]; - - edge - [ - arrowhead="open" - ] - - // Program elements. - { - operating_system [ label="Operating System", shape=ellipse ]; - io_context [ label="io_context" ]; - io_object [ label="I/O Object\ne.g. socket" ]; - your_program [ label="Your Program" ]; - your_completion_handler [ label="Your Completion Handler" ]; - } - - // Owning relationships. - { - edge [ arrowtail="diamond" ]; - your_program:e -> your_completion_handler:n; - your_program:w -> io_object:nw; - your_program:se -> io_context:ne; - } - - // Non-owning relationships; - { - io_object:sw -> io_context:w; - } - - // Visible actions. - { - edge [ style="dashed", color="#808080" ]; - - // Forward actions. - { - your_program:s -> io_context:n [ label="5" ]; - } - - // Reverse actions. - { - edge [ arrowhead="none", arrowtail="open" ]; - io_context:s -> operating_system:n [ label="4" ]; - your_completion_handler:s -> io_context:e [ label="6" ]; - } - } - - // Invisible actions. - { - edge [ style="invis" ]; - - // Forward actions. - { - your_program:sw -> io_object:n [ label="1" ]; - io_object:s -> io_context:nw [ label="2" ]; - //io_context:s -> operating_system:n [ label="3" ]; - } - } -} diff --git a/3rdparty/asio/src/doc/overview/async_op2.png b/3rdparty/asio/src/doc/overview/async_op2.png Binary files differdeleted file mode 100644 index ba256ec8e7f..00000000000 --- a/3rdparty/asio/src/doc/overview/async_op2.png +++ /dev/null diff --git a/3rdparty/asio/src/doc/overview/basics.qbk b/3rdparty/asio/src/doc/overview/basics.qbk deleted file mode 100644 index c867563840a..00000000000 --- a/3rdparty/asio/src/doc/overview/basics.qbk +++ /dev/null @@ -1,106 +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:basics Basic Asio Anatomy] - -Asio may be used to perform both synchronous and asynchronous operations on I/O -objects such as sockets. Before using Asio it may be useful to get a conceptual -picture of the various parts of Asio, your program, and how they work together. - -As an introductory example, let's consider what happens when you perform a -connect operation on a socket. We shall start by examining synchronous -operations. - -[$sync_op.png] - -[*Your program] will have at least one [*io_context] object. The [*io_context] -represents [*your program]'s link to the [*operating system]'s I/O services. - - asio::io_context io_context; - -To perform I/O operations [*your program] will need an [*I/O object] such as a -TCP socket: - - asio::ip::tcp::socket socket(io_context); - -When a synchronous connect operation is performed, the following sequence of -events occurs: - -1. [*Your program] initiates the connect operation by calling the [*I/O -object]: - - socket.connect(server_endpoint); - -2. The [*I/O object] forwards the request to the [*io_context]. - -3. The [*io_context] calls on the [*operating system] to perform the connect -operation. - -4. The [*operating system] returns the result of the operation to the -[*io_context]. - -5. The [*io_context] translates any error resulting from the operation into an -object of type `asio::error_code`. An `error_code` may be compared with -specific values, or tested as a boolean (where a `false` result means that no -error occurred). The result is then forwarded back up to the [*I/O object]. - -6. The [*I/O object] throws an exception of type `asio::system_error` if the -operation failed. If the code to initiate the operation had instead been -written as: - - asio::error_code ec; - socket.connect(server_endpoint, ec); - -then the `error_code` variable `ec` would be set to the result of the -operation, and no exception would be thrown. - -When an asynchronous operation is used, a different sequence of events occurs. - -[$async_op1.png] - -1. [*Your program] initiates the connect operation by calling the [*I/O -object]: - - socket.async_connect(server_endpoint, your_completion_handler); - -where `your_completion_handler` is a function or function object with the -signature: - - void your_completion_handler(const asio::error_code& ec); - -The exact signature required depends on the asynchronous operation being -performed. The reference documentation indicates the appropriate form for each -operation. - -2. The [*I/O object] forwards the request to the [*io_context]. - -3. The [*io_context] signals to the [*operating system] that it should start an -asynchronous connect. - -Time passes. (In the synchronous case this wait would have been contained -entirely within the duration of the connect operation.) - -[$async_op2.png] - -4. The [*operating system] indicates that the connect operation has completed -by placing the result on a queue, ready to be picked up by the [*io_context]. - -5. [*Your program] must make a call to `io_context::run()` (or to one of the -similar [*io_context] member functions) in order for the result to be -retrieved. A call to `io_context::run()` blocks while there are unfinished -asynchronous operations, so you would typically call it as soon as you have -started your first asynchronous operation. - -6. While inside the call to `io_context::run()`, the [*io_context] dequeues the -result of the operation, translates it into an `error_code`, and then passes it -to [*your completion handler]. - -This is a simplified picture of how Asio operates. You will want to delve -further into the documentation if your needs are more advanced, such as -extending Asio to perform other types of asynchronous operations. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/bsd_sockets.qbk b/3rdparty/asio/src/doc/overview/bsd_sockets.qbk deleted file mode 100644 index acc67da29d4..00000000000 --- a/3rdparty/asio/src/doc/overview/bsd_sockets.qbk +++ /dev/null @@ -1,270 +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:bsd_sockets The BSD Socket API and Asio] - -The Asio library includes a low-level socket interface based on the BSD socket -API, which is widely implemented and supported by extensive literature. It is -also used as the basis for networking APIs in other languages, like Java. This -low-level interface is designed to support the development of efficient and -scalable applications. For example, it permits programmers to exert finer -control over the number of system calls, avoid redundant data copying, minimise -the use of resources like threads, and so on. - -Unsafe and error prone aspects of the BSD socket API not included. For example, -the use of `int` to represent all sockets lacks type safety. The socket -representation in Asio uses a distinct type for each protocol, e.g. for TCP one -would use `ip::tcp::socket`, and for UDP one uses `ip::udp::socket`. - -The following table shows the mapping between the BSD socket API and Asio: - -[table - [ - [BSD Socket API Elements] - [Equivalents in Asio] - ] - [ - [socket descriptor - `int` (POSIX) or `SOCKET` (Windows)] - [ For TCP: [link asio.reference.ip__tcp.socket ip::tcp::socket], - [link asio.reference.ip__tcp.acceptor ip::tcp::acceptor] - - For UDP: [link asio.reference.ip__udp.socket ip::udp::socket] - - [link asio.reference.basic_socket basic_socket], - [link asio.reference.basic_stream_socket basic_stream_socket], - [link asio.reference.basic_datagram_socket basic_datagram_socket], - [link asio.reference.basic_raw_socket basic_raw_socket] ] - ] - [ - [`in_addr`, - `in6_addr`] - [ [link asio.reference.ip__address ip::address], - [link asio.reference.ip__address ip::address_v4], - [link asio.reference.ip__address ip::address_v6] ] - ] - [ - [`sockaddr_in`, - `sockaddr_in6`] - [ For TCP: [link asio.reference.ip__tcp.endpoint ip::tcp::endpoint] - - For UDP: [link asio.reference.ip__udp.endpoint ip::udp::endpoint] - - [link asio.reference.ip__basic_endpoint ip::basic_endpoint] ] - ] - [ - [`accept()`] - [ For TCP: [link asio.reference.basic_socket_acceptor.accept ip::tcp::acceptor::accept()] - - [link asio.reference.basic_socket_acceptor.accept basic_socket_acceptor::accept()] ] - ] - [ - [`bind()`] - [ For TCP: [link asio.reference.basic_socket.bind ip::tcp::acceptor::bind()], - [link asio.reference.basic_socket.bind ip::tcp::socket::bind()] - - For UDP: [link asio.reference.basic_socket.bind ip::udp::socket::bind()] - - [link asio.reference.basic_socket.bind basic_socket::bind()] ] - ] - [ - [`close()`] - [ For TCP: [link asio.reference.basic_socket.close ip::tcp::acceptor::close()], - [link asio.reference.basic_socket.close ip::tcp::socket::close()] - - For UDP: [link asio.reference.basic_socket.close ip::udp::socket::close()] - - [link asio.reference.basic_socket.close basic_socket::close()] ] - ] - [ - [`connect()`] - [ For TCP: [link asio.reference.basic_socket.connect ip::tcp::socket::connect()] - - For UDP: [link asio.reference.basic_socket.connect ip::udp::socket::connect()] - - [link asio.reference.basic_socket.connect basic_socket::connect()] ] - ] - [ - [`getaddrinfo()`, - `gethostbyaddr()`, - `gethostbyname()`, - `getnameinfo()`, - `getservbyname()`, - `getservbyport()`] - [ For TCP: [link asio.reference.ip__basic_resolver.resolve ip::tcp::resolver::resolve()], - [link asio.reference.ip__basic_resolver.async_resolve ip::tcp::resolver::async_resolve()] - - For UDP: [link asio.reference.ip__basic_resolver.resolve ip::udp::resolver::resolve()], - [link asio.reference.ip__basic_resolver.async_resolve ip::udp::resolver::async_resolve()] - - [link asio.reference.ip__basic_resolver.resolve ip::basic_resolver::resolve()], - [link asio.reference.ip__basic_resolver.async_resolve ip::basic_resolver::async_resolve()] ] - ] - [ - [`gethostname()`] - [ [link asio.reference.ip__host_name ip::host_name()] ] - ] - [ - [`getpeername()`] - [ For TCP: [link asio.reference.basic_socket.remote_endpoint ip::tcp::socket::remote_endpoint()] - - For UDP: [link asio.reference.basic_socket.remote_endpoint ip::udp::socket::remote_endpoint()] - - [link asio.reference.basic_socket.remote_endpoint basic_socket::remote_endpoint()] ] - ] - [ - [`getsockname()`] - [ For TCP: [link asio.reference.basic_socket.local_endpoint ip::tcp::acceptor::local_endpoint()], - [link asio.reference.basic_socket.local_endpoint ip::tcp::socket::local_endpoint()] - - For UDP: [link asio.reference.basic_socket.local_endpoint ip::udp::socket::local_endpoint()] - - [link asio.reference.basic_socket.local_endpoint basic_socket::local_endpoint()] ] - ] - [ - [`getsockopt()`] - [ For TCP: [link asio.reference.basic_socket.get_option ip::tcp::acceptor::get_option()], - [link asio.reference.basic_socket.get_option ip::tcp::socket::get_option()] - - For UDP: [link asio.reference.basic_socket.get_option ip::udp::socket::get_option()] - - [link asio.reference.basic_socket.get_option basic_socket::get_option()] ] - ] - [ - [`inet_addr()`, - `inet_aton()`, - `inet_pton()`] - [ [link asio.reference.ip__address.from_string ip::address::from_string()], - [link asio.reference.ip__address.from_string ip::address_v4::from_string()], - [link asio.reference.ip__address.from_string ip_address_v6::from_string()] ] - ] - [ - [`inet_ntoa()`, - `inet_ntop()`] - [ [link asio.reference.ip__address.to_string ip::address::to_string()], - [link asio.reference.ip__address.to_string ip::address_v4::to_string()], - [link asio.reference.ip__address.to_string ip_address_v6::to_string()] ] - ] - [ - [`ioctl()`] - [ For TCP: [link asio.reference.basic_socket.io_control ip::tcp::socket::io_control()] - - For UDP: [link asio.reference.basic_socket.io_control ip::udp::socket::io_control()] - - [link asio.reference.basic_socket.io_control basic_socket::io_control()] ] - ] - [ - [`listen()`] - [ For TCP: [link asio.reference.basic_socket_acceptor.listen ip::tcp::acceptor::listen()] - - [link asio.reference.basic_socket_acceptor.listen basic_socket_acceptor::listen()] ] - ] - [ - [`poll()`, - `select()`, - `pselect()`] - [ [link asio.reference.io_context.run io_context::run()], - [link asio.reference.io_context.run_one io_context::run_one()], - [link asio.reference.io_context.poll io_context::poll()], - [link asio.reference.io_context.poll_one io_context::poll_one()] - - Note: in conjunction with asynchronous operations. ] - ] - [ - [`readv()`, - `recv()`, - `read()`] - [ For TCP: [link asio.reference.basic_stream_socket.read_some ip::tcp::socket::read_some()], - [link asio.reference.basic_stream_socket.async_read_some ip::tcp::socket::async_read_some()], - [link asio.reference.basic_stream_socket.receive ip::tcp::socket::receive()], - [link asio.reference.basic_stream_socket.async_receive ip::tcp::socket::async_receive()] - - For UDP: [link asio.reference.basic_datagram_socket.receive ip::udp::socket::receive()], - [link asio.reference.basic_datagram_socket.async_receive ip::udp::socket::async_receive()] - - [link asio.reference.basic_stream_socket.read_some basic_stream_socket::read_some()], - [link asio.reference.basic_stream_socket.async_read_some basic_stream_socket::async_read_some()], - [link asio.reference.basic_stream_socket.receive basic_stream_socket::receive()], - [link asio.reference.basic_stream_socket.async_receive basic_stream_socket::async_receive()], - [link asio.reference.basic_datagram_socket.receive basic_datagram_socket::receive()], - [link asio.reference.basic_datagram_socket.async_receive basic_datagram_socket::async_receive()] ] - ] - [ - [`recvfrom()`] - [ For UDP: [link asio.reference.basic_datagram_socket.receive_from ip::udp::socket::receive_from()], - [link asio.reference.basic_datagram_socket.async_receive_from ip::udp::socket::async_receive_from()] - - [link asio.reference.basic_datagram_socket.receive_from basic_datagram_socket::receive_from()], - [link asio.reference.basic_datagram_socket.async_receive_from basic_datagram_socket::async_receive_from()] ] - ] - [ - [`send()`, - `write()`, - `writev()`] - [ For TCP: [link asio.reference.basic_stream_socket.write_some ip::tcp::socket::write_some()], - [link asio.reference.basic_stream_socket.async_write_some ip::tcp::socket::async_write_some()], - [link asio.reference.basic_stream_socket.send ip::tcp::socket::send()], - [link asio.reference.basic_stream_socket.async_send ip::tcp::socket::async_send()] - - For UDP: [link asio.reference.basic_datagram_socket.send ip::udp::socket::send()], - [link asio.reference.basic_datagram_socket.async_send ip::udp::socket::async_send()] - - [link asio.reference.basic_stream_socket.write_some basic_stream_socket::write_some()], - [link asio.reference.basic_stream_socket.async_write_some basic_stream_socket::async_write_some()], - [link asio.reference.basic_stream_socket.send basic_stream_socket::send()], - [link asio.reference.basic_stream_socket.async_send basic_stream_socket::async_send()], - [link asio.reference.basic_datagram_socket.send basic_datagram_socket::send()], - [link asio.reference.basic_datagram_socket.async_send basic_datagram_socket::async_send()] ] - ] - [ - [`sendto()`] - [ For UDP: [link asio.reference.basic_datagram_socket.send_to ip::udp::socket::send_to()], - [link asio.reference.basic_datagram_socket.async_send_to ip::udp::socket::async_send_to()] - - [link asio.reference.basic_datagram_socket.send_to basic_datagram_socket::send_to()], - [link asio.reference.basic_datagram_socket.async_send_to basic_datagram_socket::async_send_to()] ] - ] - [ - [`setsockopt()`] - [ For TCP: [link asio.reference.basic_socket.set_option ip::tcp::acceptor::set_option()], - [link asio.reference.basic_socket.set_option ip::tcp::socket::set_option()] - - For UDP: [link asio.reference.basic_socket.set_option ip::udp::socket::set_option()] - - [link asio.reference.basic_socket.set_option basic_socket::set_option()] ] - ] - [ - [`shutdown()`] - [ For TCP: [link asio.reference.basic_socket.shutdown ip::tcp::socket::shutdown()] - - For UDP: [link asio.reference.basic_socket.shutdown ip::udp::socket::shutdown()] - - [link asio.reference.basic_socket.shutdown basic_socket::shutdown()] ] - ] - [ - [`sockatmark()`] - [ For TCP: [link asio.reference.basic_socket.at_mark ip::tcp::socket::at_mark()] - - [link asio.reference.basic_socket.at_mark basic_socket::at_mark()] ] - ] - [ - [`socket()`] - [ For TCP: [link asio.reference.basic_socket.open ip::tcp::acceptor::open()], - [link asio.reference.basic_socket.open ip::tcp::socket::open()] - - For UDP: [link asio.reference.basic_socket.open ip::udp::socket::open()] - - [link asio.reference.basic_socket.open basic_socket::open()] ] - ] - [ - [`socketpair()`] - [ [link asio.reference.local__connect_pair local::connect_pair()] - - Note: POSIX operating systems only. ] - ] -] - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/buffers.qbk b/3rdparty/asio/src/doc/overview/buffers.qbk deleted file mode 100644 index bd8760d458f..00000000000 --- a/3rdparty/asio/src/doc/overview/buffers.qbk +++ /dev/null @@ -1,163 +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:buffers Buffers] - -Fundamentally, I/O involves the transfer of data to and from contiguous regions -of memory, called buffers. These buffers can be simply expressed as a tuple -consisting of a pointer and a size in bytes. However, to allow the development -of efficient network applications, Asio includes support for scatter-gather -operations. These operations involve one or more buffers: - -* A scatter-read receives data into multiple buffers. -* A gather-write transmits multiple buffers. - -Therefore we require an abstraction to represent a collection of buffers. The -approach used in Asio is to define a type (actually two types) to -represent a single buffer. These can be stored in a container, which may be -passed to the scatter-gather operations. - -In addition to specifying buffers as a pointer and size in bytes, Asio makes a -distinction between modifiable memory (called mutable) and non-modifiable -memory (where the latter is created from the storage for a const-qualified -variable). These two types could therefore be defined as follows: - - typedef std::pair<void*, std::size_t> mutable_buffer; - typedef std::pair<const void*, std::size_t> const_buffer; - -Here, a mutable_buffer would be convertible to a const_buffer, but conversion -in the opposite direction is not valid. - -However, Asio does not use the above definitions as-is, but instead defines two -classes: `mutable_buffer` and `const_buffer`. The goal of these is to provide -an opaque representation of contiguous memory, where: - -* Types behave as std::pair would in conversions. That is, a `mutable_buffer` is - convertible to a `const_buffer`, but the opposite conversion is disallowed. - -* There is protection against buffer overruns. Given a buffer instance, a user - can only create another buffer representing the same range of memory or a - sub-range of it. To provide further safety, the library also includes - mechanisms for automatically determining the size of a buffer from an array, - `boost::array` or `std::vector` of POD elements, or from a `std::string`. - -* The underlying memory is explicitly accessed using the `data()` member - function. In general an application should never need to do this, but it is - required by the library implementation to pass the raw memory to the - underlying operating system functions. - -Finally, multiple buffers can be passed to scatter-gather operations (such as -[link asio.reference.read read()] or [link asio.reference.write write()]) by -putting the buffer objects into a container. The `MutableBufferSequence` and -`ConstBufferSequence` concepts have been defined so that containers such as -`std::vector`, `std::list`, `std::vector` or `boost::array` can be used. - -[heading Streambuf for Integration with Iostreams] - -The class `asio::basic_streambuf` is derived from `std::basic_streambuf` to -associate the input sequence and output sequence with one or more objects of -some character array type, whose elements store arbitrary values. These -character array objects are internal to the streambuf object, but direct access -to the array elements is provided to permit them to be used with I/O -operations, such as the send or receive operations of a socket: - -* The input sequence of the streambuf is accessible via the [link - asio.reference.basic_streambuf.data data()] member function. The return type - of this function meets the `ConstBufferSequence` requirements. - -* The output sequence of the streambuf is accessible via the [link - asio.reference.basic_streambuf.data prepare()] member function. The return - type of this function meets the `MutableBufferSequence` requirements. - -* Data is transferred from the front of the output sequence to the back of the - input sequence by calling the [link asio.reference.basic_streambuf.commit - commit()] member function. - -* Data is removed from the front of the input sequence by calling the [link - asio.reference.basic_streambuf.consume consume()] member function. - -The streambuf constructor accepts a `size_t` argument specifying the maximum of -the sum of the sizes of the input sequence and output sequence. Any operation -that would, if successful, grow the internal data beyond this limit will throw -a `std::length_error` exception. - -[heading Bytewise Traversal of Buffer Sequences] - -The `buffers_iterator<>` class template allows buffer sequences (i.e. types -meeting `MutableBufferSequence` or `ConstBufferSequence` requirements) to be -traversed as though they were a contiguous sequence of bytes. Helper functions -called buffers_begin() and buffers_end() are also provided, where the -buffers_iterator<> template parameter is automatically deduced. - -As an example, to read a single line from a socket and into a `std::string`, -you may write: - - asio::streambuf sb; - ... - std::size_t n = asio::read_until(sock, sb, '\n'); - asio::streambuf::const_buffers_type bufs = sb.data(); - std::string line( - asio::buffers_begin(bufs), - asio::buffers_begin(bufs) + n); - -[heading Buffer Debugging] - -Some standard library implementations, such as the one that ships with -Microsoft Visual C++ 8.0 and later, provide a feature called iterator -debugging. What this means is that the validity of iterators is checked at -runtime. If a program tries to use an iterator that has been invalidated, an -assertion will be triggered. For example: - - std::vector<int> v(1) - std::vector<int>::iterator i = v.begin(); - v.clear(); // invalidates iterators - *i = 0; // assertion! - -Asio takes advantage of this feature to add buffer debugging. Consider the -following code: - - void dont_do_this() - { - std::string msg = "Hello, world!"; - asio::async_write(sock, asio::buffer(msg), my_handler); - } - -When you call an asynchronous read or write you need to ensure that the buffers -for the operation are valid until the completion handler is called. In the -above example, the buffer is the `std::string` variable `msg`. This variable is -on the stack, and so it goes out of scope before the asynchronous operation -completes. If you're lucky then the application will crash, but random failures -are more likely. - -When buffer debugging is enabled, Asio stores an iterator into the string until -the asynchronous operation completes, and then dereferences it to check its -validity. In the above example you would observe an assertion failure just -before Asio tries to call the completion handler. - -This feature is automatically made available for Microsoft Visual Studio 8.0 or -later and for GCC when `_GLIBCXX_DEBUG` is defined. There is a performance cost -to this checking, so buffer debugging is only enabled in debug builds. For -other compilers it may be enabled by defining `ASIO_ENABLE_BUFFER_DEBUGGING`. -It can also be explicitly disabled by defining `ASIO_DISABLE_BUFFER_DEBUGGING`. - -[heading See Also] - -[link asio.reference.buffer buffer], -[link asio.reference.buffers_begin buffers_begin], -[link asio.reference.buffers_end buffers_end], -[link asio.reference.buffers_iterator buffers_iterator], -[link asio.reference.const_buffer const_buffer], -[link asio.reference.const_buffers_1 const_buffers_1], -[link asio.reference.mutable_buffer mutable_buffer], -[link asio.reference.mutable_buffers_1 mutable_buffers_1], -[link asio.reference.streambuf streambuf], -[link asio.reference.ConstBufferSequence ConstBufferSequence], -[link asio.reference.MutableBufferSequence MutableBufferSequence], -[link asio.examples.cpp03_examples.buffers buffers example (C++03)], -[link asio.examples.cpp11_examples.buffers buffers example (c++11)]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/coroutine.qbk b/3rdparty/asio/src/doc/overview/coroutine.qbk deleted file mode 100644 index 67453674eae..00000000000 --- a/3rdparty/asio/src/doc/overview/coroutine.qbk +++ /dev/null @@ -1,51 +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:coroutine Stackless Coroutines] - -The [link asio.reference.coroutine `coroutine`] class provides support for -stackless coroutines. Stackless coroutines enable programs to implement -asynchronous logic in a synchronous manner, with minimal overhead, as shown in -the following example: - - struct session : asio::coroutine - { - boost::shared_ptr<tcp::socket> socket_; - boost::shared_ptr<std::vector<char> > buffer_; - - session(boost::shared_ptr<tcp::socket> socket) - : socket_(socket), - buffer_(new std::vector<char>(1024)) - { - } - - void operator()(asio::error_code ec = asio::error_code(), std::size_t n = 0) - { - if (!ec) reenter (this) - { - for (;;) - { - yield socket_->async_read_some(asio::buffer(*buffer_), *this); - yield asio::async_write(*socket_, asio::buffer(*buffer_, n), *this); - } - } - } - }; - -The `coroutine` class is used in conjunction with the pseudo-keywords -`reenter`, `yield` and `fork`. These are preprocessor macros, and are -implemented in terms of a `switch` statement using a technique similar to -Duff's Device. The [link asio.reference.coroutine `coroutine`] class's -documentation provides a complete description of these pseudo-keywords. - -[heading See Also] - -[link asio.reference.coroutine coroutine], -[link asio.examples.cpp03_examples.http_server_4 HTTP Server 4 example], -[link asio.overview.core.spawn Stackful Coroutines]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/cpp2011.qbk b/3rdparty/asio/src/doc/overview/cpp2011.qbk deleted file mode 100644 index fa9e6622b67..00000000000 --- a/3rdparty/asio/src/doc/overview/cpp2011.qbk +++ /dev/null @@ -1,275 +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:cpp2011 C++ 2011 Support] - -[/boostify: non-boost docs start here] - -[link asio.overview.cpp2011.system_error System Errors and Error Codes] - -[/boostify: non-boost docs end here] - -[link asio.overview.cpp2011.move_objects Movable I/O Objects] - -[link asio.overview.cpp2011.move_handlers Movable Handlers] - -[link asio.overview.cpp2011.variadic Variadic Templates] - -[link asio.overview.cpp2011.array Array Container] - -[link asio.overview.cpp2011.atomic Atomics] - -[link asio.overview.cpp2011.shared_ptr Shared Pointers] - -[link asio.overview.cpp2011.chrono Chrono] - -[link asio.overview.cpp2011.futures Futures] - -[/boostify: non-boost docs start here] - -[section:system_error System Errors and Error Codes] - -When available, Asio can use the `std::error_code` and `std::system_error` -classes for reporting errors. In this case, the names `asio::error_code` and -`asio::system_error` will be typedefs for these standard classes. - -System error support is automatically enabled for [^g++] 4.6 and later, when -the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It may be -disabled by defining `ASIO_DISABLE_STD_SYSTEM_ERROR`, or explicitly enabled for -other compilers by defining `ASIO_HAS_STD_SYSTEM_ERROR`. - -[endsect] - -[/boostify: non-boost docs end here] - -[section:move_objects Movable I/O Objects] - -When move support is available (via rvalue references), Asio allows move -construction and assignment of sockets, serial ports, POSIX descriptors and -Windows handles. - -Move support allows you to write code like: - - tcp::socket make_socket(io_context& i) - { - tcp::socket s(i); - ... - std::move(s); - } - -or: - - class connection : public enable_shared_from_this<connection> - { - private: - tcp::socket socket_; - ... - public: - connection(tcp::socket&& s) : socket_(std::move(s)) {} - ... - }; - - ... - - class server - { - private: - tcp::acceptor acceptor_; - tcp::socket socket_; - ... - void handle_accept(error_code ec) - { - if (!ec) - std::make_shared<connection>(std::move(socket_))->go(); - acceptor_.async_accept(socket_, ...); - } - ... - }; - -as well as: - - std::vector<tcp::socket> sockets; - sockets.push_back(tcp::socket(...)); - -A word of warning: There is nothing stopping you from moving these objects -while there are pending asynchronous operations, but it is unlikely to be a -good idea to do so. In particular, composed operations like [link -asio.reference.async_read async_read()] store a reference to the stream object. -Moving during the composed operation means that the composed operation may -attempt to access a moved-from object. - -Move support is automatically enabled for [^g++] 4.5 and later, when the -[^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It may be disabled -by defining `ASIO_DISABLE_MOVE`, or explicitly enabled for other compilers by -defining `ASIO_HAS_MOVE`. Note that these macros also affect the availability -of [link asio.overview.cpp2011.move_handlers movable handlers]. - -[endsect] - -[section:move_handlers Movable Handlers] - -As an optimisation, user-defined completion handlers may provide move -constructors, and Asio's implementation will use a handler's move constructor -in preference to its copy constructor. In certain circumstances, Asio may be -able to eliminate all calls to a handler's copy constructor. However, handler -types are still required to be copy constructible. - -When move support is enabled, asynchronous that are documented as follows: - - template <typename Handler> - void async_XYZ(..., Handler handler); - -are actually declared as: - - template <typename Handler> - void async_XYZ(..., Handler&& handler); - -The handler argument is perfectly forwarded and the move construction occurs -within the body of `async_XYZ()`. This ensures that all other function -arguments are evaluated prior to the move. This is critical when the other -arguments to `async_XYZ()` are members of the handler. For example: - - struct my_operation - { - shared_ptr<tcp::socket> socket; - shared_ptr<vector<char>> buffer; - ... - void operator(error_code ec, size_t length) - { - ... - socket->async_read_some(asio::buffer(*buffer), std::move(*this)); - ... - } - }; - -Move support is automatically enabled for [^g++] 4.5 and later, when the -[^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It may be disabled -by defining `ASIO_DISABLE_MOVE`, or explicitly enabled for other compilers by -defining `ASIO_HAS_MOVE`. Note that these macros also affect the availability -of [link asio.overview.cpp2011.move_objects movable I/O objects]. - -[endsect] - -[section:variadic Variadic Templates] - -When supported by a compiler, Asio can use variadic templates to implement the -[link asio.reference.basic_socket_streambuf.connect -basic_socket_streambuf::connect()] and [link -asio.reference.basic_socket_iostream.connect basic_socket_iostream::connect()] -functions. - -Support for variadic templates is automatically enabled for [^g++] 4.3 and -later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used. It -may be disabled by defining `ASIO_DISABLE_VARIADIC_TEMPLATES`, or explicitly -enabled for other compilers by defining `ASIO_HAS_VARIADIC_TEMPLATES`. - -[endsect] - -[section:array Array Container] - -Where the standard library provides `std::array<>`, Asio: - -* Provides overloads for the [link asio.reference.buffer buffer()] function. - -* Uses it in preference to `boost::array<>` for the - [link asio.reference.ip__address_v4.bytes_type ip::address_v4::bytes_type] and - [link asio.reference.ip__address_v6.bytes_type ip::address_v6::bytes_type] - types. - -* Uses it in preference to `boost::array<>` where a fixed size array type is - needed in the implementation. - -Support for `std::array<>` is automatically enabled for [^g++] 4.3 and later, -when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used, as well as -for Microsoft Visual C++ 10. It may be disabled by defining -`ASIO_DISABLE_STD_ARRAY`, or explicitly enabled for other compilers by -defining `ASIO_HAS_STD_ARRAY`. - -[endsect] - -[section:atomic Atomics] - -Asio's implementation can use `std::atomic<>` in preference to -`boost::detail::atomic_count`. - -Support for the standard atomic integer template is automatically enabled for -[^g++] 4.5 and later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler -options are used. It may be disabled by defining `ASIO_DISABLE_STD_ATOMIC`, or -explicitly enabled for other compilers by defining `ASIO_HAS_STD_ATOMIC`. - -[endsect] - -[section:shared_ptr Shared Pointers] - -Asio's implementation can use `std::shared_ptr<>` and `std::weak_ptr<>` in -preference to the Boost equivalents. - -Support for the standard smart pointers is automatically enabled for [^g++] 4.3 -and later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are used, -as well as for Microsoft Visual C++ 10. It may be disabled by defining -`ASIO_DISABLE_STD_SHARED_PTR`, or explicitly enabled for other compilers by -defining `ASIO_HAS_STD_SHARED_PTR`. - -[endsect] - -[section:chrono Chrono] - -Asio provides timers based on the `std::chrono` facilities via the [link -asio.reference.basic_waitable_timer basic_waitable_timer] class template. -The typedefs [link asio.reference.system_timer system_timer], [link -asio.reference.steady_timer steady_timer] and [link -asio.reference.high_resolution_timer high_resolution_timer] utilise the -standard clocks `system_clock`, `steady_clock` and `high_resolution_clock` -respectively. - -Support for the `std::chrono` facilities is automatically enabled for [^g++] -4.6 and later, when the [^-std=c++0x] or [^-std=gnu++0x] compiler options are -used. (Note that, for [^g++], the draft-standard `monotonic_clock` is used in -place of `steady_clock`.) Support may be disabled by defining -`ASIO_DISABLE_STD_CHRONO`, or explicitly enabled for other compilers by -defining `ASIO_HAS_STD_CHRONO`. - -When standard `chrono` is unavailable, Asio will otherwise use the Boost.Chrono -library. The [link asio.reference.basic_waitable_timer basic_waitable_timer] -class template may be used with either. - -[endsect] - -[section:futures Futures] - -The `asio::use_future` special value provides first-class support for returning a -C++11 `std::future` from an asynchronous operation's initiating function. - -To use `asio::use_future`, pass it to an asynchronous operation instead of -a normal completion handler. For example: - - std::future<std::size_t> length = - my_socket.async_read_some(my_buffer, asio::use_future); - -Where a handler signature has the form: - - void handler(asio::error_code ec, result_type result); - -the initiating function returns a `std::future` templated on `result_type`. -In the above example, this is `std::size_t`. If the asynchronous operation -fails, the `error_code` is converted into a `system_error` exception and -passed back to the caller through the future. - -Where a handler signature has the form: - - void handler(asio::error_code ec); - -the initiating function returns `std::future<void>`. As above, an error -is passed back in the future as a `system_error` exception. - -[link asio.reference.use_future use_future], -[link asio.reference.use_future_t use_future_t], -[link asio.examples.cpp11_examples.futures Futures example (C++11)]. - -[endsect] - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/handler_tracking.qbk b/3rdparty/asio/src/doc/overview/handler_tracking.qbk deleted file mode 100644 index 3c2635254b5..00000000000 --- a/3rdparty/asio/src/doc/overview/handler_tracking.qbk +++ /dev/null @@ -1,102 +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:handler_tracking Handler Tracking] - -To aid in debugging asynchronous programs, Asio provides support for handler -tracking. When enabled by defining `ASIO_ENABLE_HANDLER_TRACKING`, Asio -writes debugging output to the standard error stream. The output records -asynchronous operations and the relationships between their handlers. - -[teletype] -This feature is useful when debugging and you need to know how your -asynchronous operations are chained together, or what the pending asynchronous -operations are. As an illustration, here is the output when you run the HTTP -Server example, handle a single request, then shut down via Ctrl+C: - - @asio|1298160085.070638|0*1|signal_set@0x7fff50528f40.async_wait - @asio|1298160085.070888|0*2|socket@0x7fff50528f60.async_accept - @asio|1298160085.070913|0|resolver@0x7fff50528e28.cancel - @asio|1298160118.075438|>2|ec=asio.system:0 - @asio|1298160118.075472|2*3|socket@0xb39048.async_receive - @asio|1298160118.075507|2*4|socket@0x7fff50528f60.async_accept - @asio|1298160118.075527|<2| - @asio|1298160118.075540|>3|ec=asio.system:0,bytes_transferred=122 - @asio|1298160118.075731|3*5|socket@0xb39048.async_send - @asio|1298160118.075778|<3| - @asio|1298160118.075793|>5|ec=asio.system:0,bytes_transferred=156 - @asio|1298160118.075831|5|socket@0xb39048.close - @asio|1298160118.075855|<5| - @asio|1298160122.827317|>1|ec=asio.system:0,signal_number=2 - @asio|1298160122.827333|1|socket@0x7fff50528f60.close - @asio|1298160122.827359|<1| - @asio|1298160122.827370|>4|ec=asio.system:125 - @asio|1298160122.827378|<4| - @asio|1298160122.827394|0|signal_set@0x7fff50528f40.cancel - -Each line is of the form: - - <tag>|<timestamp>|<action>|<description> - -The `<tag>` is always `@asio`, and is used to identify and extract the handler -tracking messages from the program output. - -The `<timestamp>` is seconds and microseconds from 1 Jan 1970 UTC. - -The `<action>` takes one of the following forms: - -[variablelist - [ - [>n] - [The program entered the handler number `n`. The `<description>` shows the - arguments to the handler.] - ] - [ - [<n] - [The program left handler number `n`.] - ] - [ - [!n] - [The program left handler number n due to an exception.] - ] - [ - [~n] - [The handler number `n` was destroyed without having been invoked. This is - usually the case for any unfinished asynchronous operations when the - `io_context` is destroyed.] - ] - [ - [n*m] - [The handler number `n` created a new asynchronous operation with completion - handler number `m`. The `<description>` shows what asynchronous operation - was started.] - ] - [ - [n] - [The handler number n performed some other operation. The `<description>` - shows what function was called. Currently only `close()` and `cancel()` - operations are logged, as these may affect the state of pending - asynchronous operations.] - ] -] - -Where the `<description>` shows a synchronous or asynchronous operation, the -format is `<object-type>@<pointer>.<operation>`. For handler entry, it shows a -comma-separated list of arguments and their values. - -As shown above, Each handler is assigned a numeric identifier. Where the -handler tracking output shows a handler number of 0, it means that the action -was performed outside of any handler. - -[heading Visual Representations] - -The handler tracking output may be post-processed using the included -[^handlerviz.pl] tool to create a visual representation of the handlers -(requires the GraphViz tool [^dot]). -[c++] - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/implementation.qbk b/3rdparty/asio/src/doc/overview/implementation.qbk deleted file mode 100644 index 34c92f013e8..00000000000 --- a/3rdparty/asio/src/doc/overview/implementation.qbk +++ /dev/null @@ -1,305 +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:implementation Platform-Specific Implementation Notes] - -This section lists platform-specific implementation details, such as the -default demultiplexing mechanism, the number of threads created internally, and -when threads are created. - - -[heading Linux Kernel 2.4] - -Demultiplexing mechanism: - -* Uses `select` for demultiplexing. This means that the number of file -descriptors in the process cannot be permitted to exceed `FD_SETSIZE`. - -Threads: - -* Demultiplexing using `select` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - -[heading Linux Kernel 2.6] - -Demultiplexing mechanism: - -* Uses `epoll` for demultiplexing. - -Threads: - -* Demultiplexing using `epoll` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading Solaris] - -Demultiplexing mechanism: - -* Uses [^/dev/poll] for demultiplexing. - -Threads: - -* Demultiplexing using [^/dev/poll] is performed in one of the threads that -calls `io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading QNX Neutrino] - -Demultiplexing mechanism: - -* Uses `select` for demultiplexing. This means that the number of file -descriptors in the process cannot be permitted to exceed `FD_SETSIZE`. - -Threads: - -* Demultiplexing using `select` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading Mac OS X] - -Demultiplexing mechanism: - -* Uses `kqueue` for demultiplexing. - -Threads: - -* Demultiplexing using `kqueue` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading FreeBSD] - -Demultiplexing mechanism: - -* Uses `kqueue` for demultiplexing. - -Threads: - -* Demultiplexing using `kqueue` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading AIX] - -Demultiplexing mechanism: - -* Uses `select` for demultiplexing. This means that the number of file -descriptors in the process cannot be permitted to exceed `FD_SETSIZE`. - -Threads: - -* Demultiplexing using `select` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading HP-UX] - -Demultiplexing mechanism: - -* Uses `select` for demultiplexing. This means that the number of file -descriptors in the process cannot be permitted to exceed `FD_SETSIZE`. - -Threads: - -* Demultiplexing using `select` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading Tru64] - -Demultiplexing mechanism: - -* Uses `select` for demultiplexing. This means that the number of file -descriptors in the process cannot be permitted to exceed `FD_SETSIZE`. - -Threads: - -* Demultiplexing using `select` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* At most `min(64,IOV_MAX)` buffers may be transferred in a single operation. - - -[heading Windows 95, 98 and Me] - -Demultiplexing mechanism: - -* Uses `select` for demultiplexing. - -Threads: - -* Demultiplexing using `select` is performed in one of the threads that calls -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* For sockets, at most 16 buffers may be transferred in a single operation. - - -[heading Windows NT, 2000, XP, 2003, Vista, 7 and 8] - -Demultiplexing mechanism: - -* Uses overlapped I/O and I/O completion ports for all asynchronous socket -operations except for asynchronous connect. - -* Uses `select` for emulating asynchronous connect. - -Threads: - -* Demultiplexing using I/O completion ports is performed in all threads that call -`io_context::run()`, `io_context::run_one()`, `io_context::poll()` or -`io_context::poll_one()`. - -* An additional thread per `io_context` is used to trigger timers. This thread -is created on construction of the first `basic_deadline_timer` or -`basic_waitable_timer` objects. - -* An additional thread per `io_context` is used for the `select` -demultiplexing. This thread is created on the first call to `async_connect()`. - -* An additional thread per `io_context` is used to emulate asynchronous host -resolution. This thread is created on the first call to either -`ip::tcp::resolver::async_resolve()` or `ip::udp::resolver::async_resolve()`. - -Scatter-Gather: - -* For sockets, at most 64 buffers may be transferred in a single operation. - -* For stream-oriented handles, only one buffer may be transferred in a single -operation. - -[heading Windows Runtime] - -Asio provides limited support for the Windows Runtime. It requires that the -language extensions be enabled. Due to the restricted facilities exposed by the -Windows Runtime API, the support comes with the following caveats: - -* The core facilities such as the `io_context`, `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. - -Demultiplexing mechanism: - -* Uses the `Windows::Networking::Sockets::StreamSocket` class to implement - asynchronous TCP socket operations. - -Threads: - -* Event completions are delivered to the Windows thread pool and posted to the - `io_context` for the handler to be executed. - -* An additional thread per `io_context` is used to trigger timers. This thread - is created on construction of the first timer objects. - -Scatter-Gather: - -* For sockets, at most one buffer may be transferred in a single operation. - - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/iostreams.qbk b/3rdparty/asio/src/doc/overview/iostreams.qbk deleted file mode 100644 index f738f9edec5..00000000000 --- a/3rdparty/asio/src/doc/overview/iostreams.qbk +++ /dev/null @@ -1,72 +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:iostreams Socket Iostreams] - -Asio includes classes that implement iostreams on top of sockets. These hide -away the complexities associated with endpoint resolution, protocol -independence, etc. To create a connection one might simply write: - - ip::tcp::iostream stream("www.boost.org", "http"); - if (!stream) - { - // Can't connect. - } - -The iostream class can also be used in conjunction with an acceptor to create -simple servers. For example: - - io_context ioc; - - ip::tcp::endpoint endpoint(tcp::v4(), 80); - ip::tcp::acceptor acceptor(ios, endpoint); - - for (;;) - { - ip::tcp::iostream stream; - acceptor.accept(stream.socket()); - ... - } - -Timeouts may be set by calling `expires_at()` or `expires_from_now()` to -establish a deadline. Any socket operations that occur past the deadline will -put the iostream into a "bad" state. - -For example, a simple client program like this: - - ip::tcp::iostream stream; - stream.expires_from_now(boost::posix_time::seconds(60)); - stream.connect("www.boost.org", "http"); - stream << "GET /LICENSE_1_0.txt HTTP/1.0\r\n"; - stream << "Host: www.boost.org\r\n"; - stream << "Accept: */*\r\n"; - stream << "Connection: close\r\n\r\n"; - stream.flush(); - std::cout << stream.rdbuf(); - -will fail if all the socket operations combined take longer than 60 seconds. - -If an error does occur, the iostream's `error()` member function may be used to -retrieve the error code from the most recent system call: - - if (!stream) - { - std::cout << "Error: " << stream.error().message() << "\n"; - } - -[heading See Also] - -[link asio.reference.ip__tcp.iostream ip::tcp::iostream], -[link asio.reference.basic_socket_iostream basic_socket_iostream], -[link asio.examples.cpp03_examples.iostreams iostreams examples]. - -[heading Notes] - -These iostream templates only support `char`, not `wchar_t`, and do not perform -any code conversion. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/line_based.qbk b/3rdparty/asio/src/doc/overview/line_based.qbk deleted file mode 100644 index df007adc3f8..00000000000 --- a/3rdparty/asio/src/doc/overview/line_based.qbk +++ /dev/null @@ -1,118 +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:line_based Line-Based Operations] - -Many commonly-used internet protocols are line-based, which means that they -have protocol elements that are delimited by the character sequence `"\r\n"`. -Examples include HTTP, SMTP and FTP. To more easily permit the implementation -of line-based protocols, as well as other protocols that use delimiters, Asio -includes the functions `read_until()` and `async_read_until()`. - -The following example illustrates the use of `async_read_until()` in an HTTP -server, to receive the first line of an HTTP request from a client: - - class http_connection - { - ... - - void start() - { - asio::async_read_until(socket_, data_, "\r\n", - boost::bind(&http_connection::handle_request_line, this, _1)); - } - - void handle_request_line(asio::error_code ec) - { - if (!ec) - { - std::string method, uri, version; - char sp1, sp2, cr, lf; - std::istream is(&data_); - is.unsetf(std::ios_base::skipws); - is >> method >> sp1 >> uri >> sp2 >> version >> cr >> lf; - ... - } - } - - ... - - asio::ip::tcp::socket socket_; - asio::streambuf data_; - }; - -The `streambuf` data member serves as a place to store the data that has been -read from the socket before it is searched for the delimiter. It is important -to remember that there may be additional data ['after] the delimiter. This -surplus data should be left in the `streambuf` so that it may be inspected by a -subsequent call to `read_until()` or `async_read_until()`. - -The delimiters may be specified as a single `char`, a `std::string` or a -`boost::regex`. The `read_until()` and `async_read_until()` functions also -include overloads that accept a user-defined function object called a match -condition. For example, to read data into a streambuf until whitespace is -encountered: - - typedef asio::buffers_iterator< - asio::streambuf::const_buffers_type> iterator; - - std::pair<iterator, bool> - match_whitespace(iterator begin, iterator end) - { - iterator i = begin; - while (i != end) - if (std::isspace(*i++)) - return std::make_pair(i, true); - return std::make_pair(i, false); - } - ... - asio::streambuf b; - asio::read_until(s, b, match_whitespace); - -To read data into a streambuf until a matching character is found: - - class match_char - { - public: - explicit match_char(char c) : c_(c) {} - - template <typename Iterator> - std::pair<Iterator, bool> operator()( - Iterator begin, Iterator end) const - { - Iterator i = begin; - while (i != end) - if (c_ == *i++) - return std::make_pair(i, true); - return std::make_pair(i, false); - } - - private: - char c_; - }; - - namespace asio { - template <> struct is_match_condition<match_char> - : public boost::true_type {}; - } // namespace asio - ... - asio::streambuf b; - asio::read_until(s, b, match_char('a')); - -The `is_match_condition<>` type trait automatically evaluates to true for -functions, and for function objects with a nested `result_type` typedef. For -other types the trait must be explicitly specialised, as shown above. - -[heading See Also] - -[link asio.reference.async_read_until async_read_until()], -[link asio.reference.is_match_condition is_match_condition], -[link asio.reference.read_until read_until()], -[link asio.reference.streambuf streambuf], -[link asio.examples.cpp03_examples.http_client HTTP client example]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/other_protocols.qbk b/3rdparty/asio/src/doc/overview/other_protocols.qbk deleted file mode 100644 index 9a6fe077ea1..00000000000 --- a/3rdparty/asio/src/doc/overview/other_protocols.qbk +++ /dev/null @@ -1,94 +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:other_protocols Support for Other Protocols] - -Support for other socket protocols (such as Bluetooth or IRCOMM sockets) can be -added by implementing the [link asio.reference.Protocol protocol type -requirements]. However, in many cases these protocols may also be used with -Asio's generic protocol support. For this, Asio provides the following four -classes: - -* [link asio.reference.generic__datagram_protocol `generic::datagram_protocol`] -* [link asio.reference.generic__raw_protocol `generic::raw_protocol`] -* [link asio.reference.generic__seq_packet_protocol `generic::seq_packet_protocol`] -* [link asio.reference.generic__stream_protocol `generic::stream_protocol`] - -These classes implement the [link asio.reference.Protocol protocol type -requirements], but allow the user to specify the address family (e.g. `AF_INET`) -and protocol type (e.g. `IPPROTO_TCP`) at runtime. For example: - - asio::generic::stream_protocol::socket my_socket(my_io_context); - my_socket.open(asio::generic::stream_protocol(AF_INET, IPPROTO_TCP)); - ... - -An endpoint class template, [link asio.reference.generic__basic_endpoint -`asio::generic::basic_endpoint`], is included to support these protocol -classes. This endpoint can hold any other endpoint type, provided its native -representation fits into a `sockaddr_storage` object. This class will also -convert from other types that implement the [link asio.reference.Endpoint -endpoint] type requirements: - - asio::ip::tcp::endpoint my_endpoint1 = ...; - asio::generic::stream_protocol::endpoint my_endpoint2(my_endpoint1); - -The conversion is implicit, so as to support the following use cases: - - asio::generic::stream_protocol::socket my_socket(my_io_context); - asio::ip::tcp::endpoint my_endpoint = ...; - my_socket.connect(my_endpoint); - -[heading C++11 Move Construction] - -When using C++11, it is possible to perform move construction from a socket (or -acceptor) object to convert to the more generic protocol's socket (or acceptor) -type. If the protocol conversion is valid: - - Protocol1 p1 = ...; - Protocol2 p2(p1); - -then the corresponding socket conversion is allowed: - - Protocol1::socket my_socket1(my_io_context); - ... - Protocol2::socket my_socket2(std::move(my_socket1)); - -For example, one possible conversion is from a TCP socket to a generic -stream-oriented socket: - - asio::ip::tcp::socket my_socket1(my_io_context); - ... - asio::generic::stream_protocol::socket my_socket2(std::move(my_socket1)); - -These conversions are also available for move-assignment. - -These conversions are not limited to the above generic protocol classes. -User-defined protocols may take advantage of this feature by similarly ensuring -the conversion from `Protocol1` to `Protocol2` is valid, as above. - -[heading Accepting Generic Sockets] - -As a convenience, a socket acceptor's `accept()` and `async_accept()` functions -can directly accept into a different protocol's socket type, provided the -corresponding protocol conversion is valid. For example, the following is -supported because the protocol `asio::ip::tcp` is convertible to -`asio::generic::stream_protocol`: - - asio::ip::tcp::acceptor my_acceptor(my_io_context); - ... - asio::generic::stream_protocol::socket my_socket(my_io_context); - my_acceptor.accept(my_socket); - -[heading See Also] - -[link asio.reference.generic__datagram_protocol `generic::datagram_protocol`], -[link asio.reference.generic__raw_protocol `generic::raw_protocol`], -[link asio.reference.generic__seq_packet_protocol `generic::seq_packet_protocol`], -[link asio.reference.generic__stream_protocol `generic::stream_protocol`], -[link asio.reference.Protocol protocol type requirements]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/posix.qbk b/3rdparty/asio/src/doc/overview/posix.qbk deleted file mode 100644 index 19c91783e64..00000000000 --- a/3rdparty/asio/src/doc/overview/posix.qbk +++ /dev/null @@ -1,152 +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:posix POSIX-Specific Functionality] - -[link asio.overview.posix.local UNIX Domain Sockets] - -[link asio.overview.posix.stream_descriptor Stream-Oriented File Descriptors] - -[link asio.overview.posix.fork Fork] - -[section:local UNIX Domain Sockets] - -Asio provides basic support UNIX domain sockets (also known as local sockets). -The simplest use involves creating a pair of connected sockets. The following -code: - - local::stream_protocol::socket socket1(my_io_context); - local::stream_protocol::socket socket2(my_io_context); - local::connect_pair(socket1, socket2); - -will create a pair of stream-oriented sockets. To do the same for -datagram-oriented sockets, use: - - local::datagram_protocol::socket socket1(my_io_context); - local::datagram_protocol::socket socket2(my_io_context); - local::connect_pair(socket1, socket2); - -A UNIX domain socket server may be created by binding an acceptor to an -endpoint, in much the same way as one does for a TCP server: - - ::unlink("/tmp/foobar"); // Remove previous binding. - local::stream_protocol::endpoint ep("/tmp/foobar"); - local::stream_protocol::acceptor acceptor(my_io_context, ep); - local::stream_protocol::socket socket(my_io_context); - acceptor.accept(socket); - -A client that connects to this server might look like: - - local::stream_protocol::endpoint ep("/tmp/foobar"); - local::stream_protocol::socket socket(my_io_context); - socket.connect(ep); - -Transmission of file descriptors or credentials across UNIX domain sockets is -not directly supported within Asio, but may be achieved by accessing the -socket's underlying descriptor using the [link -asio.reference.basic_socket.native_handle native_handle()] member function. - -[heading See Also] - -[link asio.reference.local__connect_pair local::connect_pair], -[link asio.reference.local__datagram_protocol local::datagram_protocol], -[link asio.reference.local__datagram_protocol.endpoint local::datagram_protocol::endpoint], -[link asio.reference.local__datagram_protocol.socket local::datagram_protocol::socket], -[link asio.reference.local__stream_protocol local::stream_protocol], -[link asio.reference.local__stream_protocol.acceptor local::stream_protocol::acceptor], -[link asio.reference.local__stream_protocol.endpoint local::stream_protocol::endpoint], -[link asio.reference.local__stream_protocol.iostream local::stream_protocol::iostream], -[link asio.reference.local__stream_protocol.socket local::stream_protocol::socket], -[link asio.examples.cpp03_examples.unix_domain_sockets UNIX domain sockets examples]. - -[heading Notes] - -UNIX domain sockets are only available at compile time if supported by the -target operating system. A program may test for the macro -`ASIO_HAS_LOCAL_SOCKETS` to determine whether they are supported. - -[endsect] - -[section:stream_descriptor Stream-Oriented File Descriptors] - -Asio includes classes added to permit synchronous and asynchronous read and -write operations to be performed on POSIX file descriptors, such as pipes, -standard input and output, and various devices. - -These classes also provide limited support for regular files. This support -assumes that the underlying read and write operations provided by the operating -system never fail with `EAGAIN` or `EWOULDBLOCK`. (This assumption normally -holds for buffered file I/O.) Synchronous and asynchronous read and write -operations on file descriptors will succeed but the I/O will always be -performed immediately. Wait operations, and operations involving -`asio::null_buffers`, are not portably supported. - -For example, to perform read and write operations on standard input -and output, the following objects may be created: - - posix::stream_descriptor in(my_io_context, ::dup(STDIN_FILENO)); - posix::stream_descriptor out(my_io_context, ::dup(STDOUT_FILENO)); - -These are then used as synchronous or asynchronous read and write streams. This -means the objects can be used with any of the [link asio.reference.read -read()], [link asio.reference.async_read async_read()], [link -asio.reference.write write()], [link asio.reference.async_write async_write()], -[link asio.reference.read_until read_until()] or [link -asio.reference.async_read_until async_read_until()] free functions. - -[heading See Also] - -[link asio.reference.posix__stream_descriptor posix::stream_descriptor], -[link asio.examples.cpp03_examples.chat Chat example (C++03)], -[link asio.examples.cpp11_examples.chat Chat example (C++11)]. - -[heading Notes] - -POSIX stream descriptors are only available at compile time if supported by the -target operating system. A program may test for the macro -`ASIO_HAS_POSIX_STREAM_DESCRIPTOR` to determine whether they are supported. - -[endsect] - -[section:fork Fork] - -Asio supports programs that utilise the `fork()` system call. Provided the -program calls `io_context.notify_fork()` at the appropriate times, Asio will -recreate any internal file descriptors (such as the "self-pipe trick" -descriptor used for waking up a reactor). The notification is usually performed -as follows: - - io_context_.notify_fork(asio::io_context::fork_prepare); - if (fork() == 0) - { - io_context_.notify_fork(asio::io_context::fork_child); - ... - } - else - { - io_context_.notify_fork(asio::io_context::fork_parent); - ... - } - -User-defined services can also be made fork-aware by overriding the -`io_context::service::notify_fork()` virtual function. - -Note that any file descriptors accessible via Asio's public API (e.g. the -descriptors underlying `basic_socket<>`, `posix::stream_descriptor`, etc.) are -not altered during a fork. It is the program's responsibility to manage these -as required. - -[heading See Also] - -[link asio.reference.io_context.notify_fork io_context::notify_fork()], -[link asio.reference.io_context.fork_event io_context::fork_event], -[link asio.reference.execution_context__service.notify_fork io_context::service::notify_fork()], -[link asio.examples.cpp03_examples.fork Fork examples]. - -[endsect] - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/proactor.dot b/3rdparty/asio/src/doc/overview/proactor.dot deleted file mode 100644 index 871723408b9..00000000000 --- a/3rdparty/asio/src/doc/overview/proactor.dot +++ /dev/null @@ -1,100 +0,0 @@ -digraph g -{ - edge - [ - fontname="Helvetica", - fontsize=10, - labelfontname="Helvetica", - labelfontsize=10 - ]; - - node - [ - fontname="Helvetica", - fontsize=10, - shape=record - ]; - - initiator - [ - label="Initiator" - ]; - - async_processor - [ - label="Asynchronous\nOperation Processor" - ]; - - async_op - [ - label="Asynchronous\nOperation" - ]; - - completion_queue - [ - label="Completion\nEvent Queue" - ]; - - async_event_demuxer - [ - label="Asynchronous\nEvent Demultiplexer" - ]; - - proactor - [ - label="Proactor" - ]; - - handler - [ - label="Completion\nHandler" - ]; - - initiator -> async_processor - [ - label="uses", - style="dashed" - ]; - - initiator -> async_op - [ - label="starts", - style="dashed" - ]; - - initiator -> handler - [ - label="creates", - style="dashed" - ]; - - async_processor -> async_op - [ - label="executes", - style="dashed" - ]; - - async_processor -> completion_queue - [ - label="enqueues", - style="dashed" - ]; - - async_op -> handler; - - async_event_demuxer -> completion_queue - [ - label="dequeues", - style="dashed" - ]; - - proactor -> async_event_demuxer - [ - ]; - - proactor -> handler - [ - label="demultiplexes\n& dispatches" - style="dashed" - ]; -} diff --git a/3rdparty/asio/src/doc/overview/proactor.png b/3rdparty/asio/src/doc/overview/proactor.png Binary files differdeleted file mode 100644 index a0653b0106c..00000000000 --- a/3rdparty/asio/src/doc/overview/proactor.png +++ /dev/null diff --git a/3rdparty/asio/src/doc/overview/protocols.qbk b/3rdparty/asio/src/doc/overview/protocols.qbk deleted file mode 100644 index eed070c7511..00000000000 --- a/3rdparty/asio/src/doc/overview/protocols.qbk +++ /dev/null @@ -1,149 +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:protocols TCP, UDP and ICMP] - -Asio provides off-the-shelf support for the internet protocols TCP, UDP and -ICMP. - -[heading TCP Clients] - -Hostname resolution is performed using a resolver, where host and service names -are looked up and converted into one or more endpoints: - - ip::tcp::resolver resolver(my_io_context); - ip::tcp::resolver::query query("www.boost.org", "http"); - ip::tcp::resolver::iterator iter = resolver.resolve(query); - ip::tcp::resolver::iterator end; // End marker. - while (iter != end) - { - ip::tcp::endpoint endpoint = *iter++; - std::cout << endpoint << std::endl; - } - -The list of endpoints obtained above could contain both IPv4 and IPv6 endpoints, -so a program should try each of them until it finds one that works. This keeps the -client program independent of a specific IP version. - -To simplify the development of protocol-independent programs, TCP clients may -establish connections using the free functions [link asio.reference.connect -connect()] and [link asio.reference.async_connect async_connect()]. These -operations try each endpoint in a list until the socket is successfully -connected. For example, a single call: - - ip::tcp::socket socket(my_io_context); - asio::connect(socket, resolver.resolve(query)); - -will synchronously try all endpoints until one is successfully connected. -Similarly, an asynchronous connect may be performed by writing: - - asio::async_connect(socket_, iter, - boost::bind(&client::handle_connect, this, - asio::placeholders::error)); - - // ... - - void handle_connect(const error_code& error) - { - if (!error) - { - // Start read or write operations. - } - else - { - // Handle error. - } - } - -When a specific endpoint is available, a socket can be created and connected: - - ip::tcp::socket socket(my_io_context); - socket.connect(endpoint); - -Data may be read from or written to a connected TCP socket using the [link -asio.reference.basic_stream_socket.receive receive()], [link -asio.reference.basic_stream_socket.async_receive async_receive()], [link -asio.reference.basic_stream_socket.send send()] or [link -asio.reference.basic_stream_socket.async_send async_send()] member functions. -However, as these could result in [link asio.overview.core.streams short writes -or reads], an application will typically use the following operations instead: -[link asio.reference.read read()], [link asio.reference.async_read -async_read()], [link asio.reference.write write()] and [link -asio.reference.async_write async_write()]. - -[heading TCP Servers] - -A program uses an acceptor to accept incoming TCP connections: - - ip::tcp::acceptor acceptor(my_io_context, my_endpoint); - ... - ip::tcp::socket socket(my_io_context); - acceptor.accept(socket); - -After a socket has been successfully accepted, it may be read from or written -to as illustrated for TCP clients above. - -[heading UDP] - -UDP hostname resolution is also performed using a resolver: - - ip::udp::resolver resolver(my_io_context); - ip::udp::resolver::query query("localhost", "daytime"); - ip::udp::resolver::iterator iter = resolver.resolve(query); - ... - -A UDP socket is typically bound to a local endpoint. The following code will -create an IP version 4 UDP socket and bind it to the "any" address on port -`12345`: - - ip::udp::endpoint endpoint(ip::udp::v4(), 12345); - ip::udp::socket socket(my_io_context, endpoint); - -Data may be read from or written to an unconnected UDP socket using the [link -asio.reference.basic_datagram_socket.receive_from receive_from()], [link -asio.reference.basic_datagram_socket.async_receive_from async_receive_from()], -[link asio.reference.basic_datagram_socket.send_to send_to()] or [link -asio.reference.basic_datagram_socket.async_send_to async_send_to()] member -functions. For a connected UDP socket, use the [link -asio.reference.basic_datagram_socket.receive receive()], [link -asio.reference.basic_datagram_socket.async_receive async_receive()], [link -asio.reference.basic_datagram_socket.send send()] or [link -asio.reference.basic_datagram_socket.async_send async_send()] member functions. - -[heading ICMP] - -As with TCP and UDP, ICMP hostname resolution is performed using a resolver: - - ip::icmp::resolver resolver(my_io_context); - ip::icmp::resolver::query query("localhost", ""); - ip::icmp::resolver::iterator iter = resolver.resolve(query); - ... - -An ICMP socket may be bound to a local endpoint. The following code will create -an IP version 6 ICMP socket and bind it to the "any" address: - - ip::icmp::endpoint endpoint(ip::icmp::v6(), 0); - ip::icmp::socket socket(my_io_context, endpoint); - -The port number is not used for ICMP. - -Data may be read from or written to an unconnected ICMP socket using the [link -asio.reference.basic_raw_socket.receive_from receive_from()], [link -asio.reference.basic_raw_socket.async_receive_from async_receive_from()], -[link asio.reference.basic_raw_socket.send_to send_to()] or [link -asio.reference.basic_raw_socket.async_send_to async_send_to()] member -functions. - -[heading See Also] - -[link asio.reference.ip__tcp ip::tcp], -[link asio.reference.ip__udp ip::udp], -[link asio.reference.ip__icmp ip::icmp], -[link asio.tutorial.tutdaytime1 daytime protocol tutorials], -[link asio.examples.cpp03_examples.icmp ICMP ping example]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/rationale.qbk b/3rdparty/asio/src/doc/overview/rationale.qbk deleted file mode 100644 index 13491cd53d0..00000000000 --- a/3rdparty/asio/src/doc/overview/rationale.qbk +++ /dev/null @@ -1,54 +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:rationale Rationale] - -Most programs interact with the outside world in some way, whether it be via a -file, a network, a serial cable, or the console. Sometimes, as is the case with -networking, individual I/O operations can take a long time to complete. This -poses particular challenges to application development. - -Asio provides the tools to manage these long running operations, without -requiring programs to use concurrency models based on threads and explicit -locking. - -The Asio library is intended for programmers using C++ for systems programming, -where access to operating system functionality such as networking is often -required. In particular, Asio addresses the following goals: - -* [*Portability.] The library should support a range of commonly used operating -systems, and provide consistent behaviour across these operating systems. - -* [*Scalability.] The library should facilitate the development of network -applications that scale to thousands of concurrent connections. The library -implementation for each operating system should use the mechanism that best -enables this scalability. - -* [*Efficiency.] The library should support techniques such as scatter-gather -I/O, and allow programs to minimise data copying. - -* [*Model concepts from established APIs, such as BSD sockets.] The -BSD socket API is widely implemented and understood, and is covered in much -literature. Other programming languages often use a similar interface for -networking APIs. As far as is reasonable, Asio should leverage existing -practice. - -* [*Ease of use.] The library should provide a lower entry barrier for new -users by taking a toolkit, rather than framework, approach. That is, it should -try to minimise the up-front investment in time to just learning a few basic -rules and guidelines. After that, a library user should only need to understand -the specific functions that are being used. - -* [*Basis for further abstraction.] The library should permit the development -of other libraries that provide higher levels of abstraction. For example, -implementations of commonly used protocols such as HTTP. - -Although Asio started life focused primarily on networking, its concepts of -asynchronous I/O have been extended to include other operating system resources -such as serial ports, file descriptors, and so on. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/reactor.qbk b/3rdparty/asio/src/doc/overview/reactor.qbk deleted file mode 100644 index 468645ad4c0..00000000000 --- a/3rdparty/asio/src/doc/overview/reactor.qbk +++ /dev/null @@ -1,44 +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:reactor Reactor-Style Operations] - -Sometimes a program must be integrated with a third-party library that wants to -perform the I/O operations itself. To facilitate this, Asio includes -synchronous and asynchronous operations that may be used to wait for a socket -to become ready to read, ready to write, or to have a pending error condition. - -As an example, to perform a non-blocking read something like the following may -be used: - - ip::tcp::socket socket(my_io_context); - ... - socket.non_blocking(true); - ... - socket.async_wait(ip::tcp::socket::wait_read, read_handler); - ... - void read_handler(asio::error_code ec) - { - if (!ec) - { - std::vector<char> buf(socket.available()); - socket.read_some(buffer(buf)); - } - } - -These operations are supported for sockets on all platforms, and for the POSIX -stream-oriented descriptor classes. - -[heading See Also] - -[link asio.reference.basic_socket.wait basic_socket::wait()], -[link asio.reference.basic_socket.async_wait basic_socket::async_wait()], -[link asio.reference.basic_socket.non_blocking basic_socket::non_blocking()], -[link asio.reference.basic_socket.native_non_blocking basic_socket::native_non_blocking()], -[link asio.examples.cpp03_examples.nonblocking nonblocking example]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/serial_ports.qbk b/3rdparty/asio/src/doc/overview/serial_ports.qbk deleted file mode 100644 index dd049cd2fa1..00000000000 --- a/3rdparty/asio/src/doc/overview/serial_ports.qbk +++ /dev/null @@ -1,45 +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:serial_ports Serial Ports] - -Asio includes classes for creating and manipulating serial ports in a portable -manner. For example, a serial port may be opened using: - - serial_port port(my_io_context, name); - -where name is something like `"COM1"` on Windows, and `"/dev/ttyS0"` on POSIX -platforms. - -Once opened, the serial port may be used as a [link asio.overview.core.streams -stream]. This means the objects can be used with any of the [link -asio.reference.read read()], [link asio.reference.async_read async_read()], -[link asio.reference.write write()], [link asio.reference.async_write -async_write()], [link asio.reference.read_until read_until()] or [link -asio.reference.async_read_until async_read_until()] free functions. - -The serial port implementation also includes option classes for configuring the -port's baud rate, flow control type, parity, stop bits and character size. - -[heading See Also] - -[link asio.reference.serial_port serial_port], -[link asio.reference.serial_port_base serial_port_base], -[link asio.reference.serial_port_base__baud_rate serial_port_base::baud_rate], -[link asio.reference.serial_port_base__flow_control serial_port_base::flow_control], -[link asio.reference.serial_port_base__parity serial_port_base::parity], -[link asio.reference.serial_port_base__stop_bits serial_port_base::stop_bits], -[link asio.reference.serial_port_base__character_size serial_port_base::character_size]. - -[heading Notes] - -Serial ports are available on all POSIX platforms. For Windows, serial ports -are only available at compile time when the I/O completion port backend is used -(which is the default). A program may test for the macro -`ASIO_HAS_SERIAL_PORT` to determine whether they are supported. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/signals.qbk b/3rdparty/asio/src/doc/overview/signals.qbk deleted file mode 100644 index d626ead861c..00000000000 --- a/3rdparty/asio/src/doc/overview/signals.qbk +++ /dev/null @@ -1,44 +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:signals Signal Handling] - -Asio supports signal handling using a class called [link -asio.reference.signal_set signal_set]. Programs may add one or more signals to -the set, and then perform an `async_wait()` operation. The specified handler -will be called when one of the signals occurs. The same signal number may be -registered with multiple [link asio.reference.signal_set signal_set] objects, -however the signal number must be used only with Asio. - - void handler( - const asio::error_code& error, - int signal_number) - { - if (!error) - { - // A signal occurred. - } - } - - ... - - // Construct a signal set registered for process termination. - asio::signal_set signals(io_context, SIGINT, SIGTERM); - - // Start an asynchronous wait for one of the signals to occur. - signals.async_wait(handler); - -Signal handling also works on Windows, as the Microsoft Visual C++ runtime -library maps console events like Ctrl+C to the equivalent signal. - -[heading See Also] - -[link asio.reference.signal_set signal_set], -[link asio.examples.cpp03_examples.http_server HTTP server example (C++03)], -[link asio.examples.cpp11_examples.http_server HTTP server example (C++11)]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/spawn.qbk b/3rdparty/asio/src/doc/overview/spawn.qbk deleted file mode 100644 index 908d78f72ae..00000000000 --- a/3rdparty/asio/src/doc/overview/spawn.qbk +++ /dev/null @@ -1,102 +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:spawn Stackful Coroutines] - -The [link asio.reference.spawn `spawn()`] function is a high-level wrapper for -running stackful coroutines. It is based on the Boost.Coroutine library. The -`spawn()` function enables programs to implement asynchronous logic in a -synchronous manner, as shown in the following example: - - asio::spawn(my_strand, do_echo); - - // ... - - void do_echo(asio::yield_context yield) - { - try - { - char data[128]; - for (;;) - { - std::size_t length = - my_socket.async_read_some( - asio::buffer(data), yield); - - asio::async_write(my_socket, - asio::buffer(data, length), yield); - } - } - catch (std::exception& e) - { - // ... - } - } - -The first argument to `spawn()` may be a -[link asio.reference.io_context__strand `strand`], -[link asio.reference.io_context `io_context`], or -[link asio.reference.CompletionHandler completion handler]. -This argument determines the context in which the coroutine is permitted to -execute. For example, a server's per-client object may consist of multiple -coroutines; they should all run on the same `strand` so that no explicit -synchronisation is required. - -The second argument is a function object with signature: - - void coroutine(asio::yield_context yield); - -that specifies the code to be run as part of the coroutine. The parameter -`yield` may be passed to an asynchronous operation in place of the completion -handler, as in: - - std::size_t length = - my_socket.async_read_some( - asio::buffer(data), yield); - -This starts the asynchronous operation and suspends the coroutine. The -coroutine will be resumed automatically when the asynchronous operation -completes. - -Where an asynchronous operation's handler signature has the form: - - void handler(asio::error_code ec, result_type result); - -the initiating function returns the result_type. In the `async_read_some` -example above, this is `size_t`. If the asynchronous operation fails, the -`error_code` is converted into a `system_error` exception and thrown. - -Where a handler signature has the form: - - void handler(asio::error_code ec); - -the initiating function returns `void`. As above, an error is passed back to -the coroutine as a `system_error` exception. - -To collect the `error_code` from an operation, rather than have it throw an -exception, associate the output variable with the `yield_context` as follows: - - asio::error_code ec; - std::size_t length = - my_socket.async_read_some( - asio::buffer(data), yield[ec]); - -[*Note:] if `spawn()` is used with a custom completion handler of type -`Handler`, the function object signature is actually: - - void coroutine(asio::basic_yield_context<Handler> yield); - -[heading See Also] - -[link asio.reference.spawn spawn], -[link asio.reference.yield_context yield_context], -[link asio.reference.basic_yield_context basic_yield_context], -[link asio.examples.cpp03_examples.spawn Spawn example (C++03)], -[link asio.examples.cpp11_examples.spawn Spawn example (C++11)], -[link asio.overview.core.coroutine Stackless Coroutines]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/ssl.qbk b/3rdparty/asio/src/doc/overview/ssl.qbk deleted file mode 100644 index e5a4d73c010..00000000000 --- a/3rdparty/asio/src/doc/overview/ssl.qbk +++ /dev/null @@ -1,123 +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:ssl SSL] - -Asio contains classes and class templates for basic SSL support. These classes -allow encrypted communication to be layered on top of an existing stream, such -as a TCP socket. - -Before creating an encrypted stream, an application must construct an SSL -context object. This object is used to set SSL options such as verification -mode, certificate files, and so on. As an illustration, client-side -initialisation may look something like: - - ssl::context ctx(ssl::context::sslv23); - ctx.set_verify_mode(ssl::verify_peer); - ctx.load_verify_file("ca.pem"); - -To use SSL with a TCP socket, one may write: - - ssl::stream<ip::tcp::socket> ssl_sock(my_io_context, ctx); - -To perform socket-specific operations, such as establishing an outbound -connection or accepting an incoming one, the underlying socket must first be -obtained using the `ssl::stream` template's [link -asio.reference.ssl__stream.lowest_layer `lowest_layer()`] member function: - - ip::tcp::socket::lowest_layer_type& sock = ssl_sock.lowest_layer(); - sock.connect(my_endpoint); - -In some use cases the underlying stream object will need to have a longer -lifetime than the SSL stream, in which case the template parameter should be a -reference to the stream type: - - ip::tcp::socket sock(my_io_context); - ssl::stream<ip::tcp::socket&> ssl_sock(sock, ctx); - -SSL handshaking must be performed prior to transmitting or receiving data over -an encrypted connection. This is accomplished using the `ssl::stream` -template's [link asio.reference.ssl__stream.handshake handshake()] or [link -asio.reference.ssl__stream.async_handshake async_handshake()] member functions. - -Once connected, SSL stream objects are used as synchronous or asynchronous read -and write streams. This means the objects can be used with any of the [link -asio.reference.read read()], [link asio.reference.async_read async_read()], -[link asio.reference.write write()], [link asio.reference.async_write -async_write()], [link asio.reference.read_until read_until()] or [link -asio.reference.async_read_until async_read_until()] free functions. - -[heading Certificate Verification] - -Asio provides various methods for configuring the way SSL certificates are -verified: - -* [link asio.reference.ssl__context.set_default_verify_paths ssl::context::set_default_verify_paths()] -* [link asio.reference.ssl__context.set_verify_mode ssl::context::set_verify_mode()] -* [link asio.reference.ssl__context.set_verify_callback ssl::context::set_verify_callback()] -* [link asio.reference.ssl__context.load_verify_file ssl::context::load_verify_file()] -* [link asio.reference.ssl__stream.set_verify_mode ssl::stream::set_verify_mode()] -* [link asio.reference.ssl__stream.set_verify_callback ssl::stream::set_verify_callback()] - -To simplify use cases where certificates are verified according to the rules in -RFC 2818 (certificate verification for HTTPS), Asio provides a reusable -verification callback as a function object: - -* [link asio.reference.ssl__rfc2818_verification ssl::rfc2818_verification] - -The following example shows verification of a remote host's certificate -according to the rules used by HTTPS: - - using asio::ip::tcp; - namespace ssl = asio::ssl; - typedef ssl::stream<tcp::socket> ssl_socket; - - // Create a context that uses the default paths for - // finding CA certificates. - ssl::context ctx(ssl::context::sslv23); - ctx.set_default_verify_paths(); - - // Open a socket and connect it to the remote host. - asio::io_context io_context; - ssl_socket sock(io_context, ctx); - tcp::resolver resolver(io_context); - tcp::resolver::query query("host.name", "https"); - asio::connect(sock.lowest_layer(), resolver.resolve(query)); - sock.lowest_layer().set_option(tcp::no_delay(true)); - - // Perform SSL handshake and verify the remote host's - // certificate. - sock.set_verify_mode(ssl::verify_peer); - sock.set_verify_callback(ssl::rfc2818_verification("host.name")); - sock.handshake(ssl_socket::client); - - // ... read and write as normal ... - -[heading SSL and Threads] - -SSL stream objects perform no locking of their own. Therefore, it is essential -that all asynchronous SSL operations are performed in an implicit or explicit -[link asio.overview.core.strands strand]. Note that this means that no -synchronisation is required (and so no locking overhead is incurred) in single -threaded programs. - -[heading See Also] - -[link asio.reference.ssl__context ssl::context], -[link asio.reference.ssl__rfc2818_verification ssl::rfc2818_verification], -[link asio.reference.ssl__stream ssl::stream], -[link asio.examples.cpp03_examples.ssl SSL example]. - -[heading Notes] - -[@http://www.openssl.org OpenSSL] is required to make use of Asio's SSL -support. When an application needs to use OpenSSL functionality that is not -wrapped by Asio, the underlying OpenSSL types may be obtained by calling [link -asio.reference.ssl__context.native_handle `ssl::context::native_handle()`] or -[link asio.reference.ssl__stream.native_handle `ssl::stream::native_handle()`]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/strands.qbk b/3rdparty/asio/src/doc/overview/strands.qbk deleted file mode 100644 index 0b6ff050dc6..00000000000 --- a/3rdparty/asio/src/doc/overview/strands.qbk +++ /dev/null @@ -1,85 +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:strands Strands: Use Threads Without Explicit Locking] - -A strand is defined as a strictly sequential invocation of event handlers (i.e. -no concurrent invocation). Use of strands allows execution of code in a -multithreaded program without the need for explicit locking (e.g. using -mutexes). - -Strands may be either implicit or explicit, as illustrated by the following -alternative approaches: - -* Calling io_context::run() from only one thread means all event handlers - execute in an implicit strand, due to the io_context's guarantee that handlers - are only invoked from inside run(). - -* Where there is a single chain of asynchronous operations associated with a - connection (e.g. in a half duplex protocol implementation like HTTP) there is - no possibility of concurrent execution of the handlers. This is an implicit - strand. - -* An explicit strand is an instance of `strand<>` or `io_context::strand`. All - event handler function objects need to be bound to the strand using - `asio::bind_executor()` or otherwise posted/dispatched through the strand - object. - -In the case of composed asynchronous operations, such as `async_read()` or -`async_read_until()`, if a completion handler goes through a strand, then all -intermediate handlers should also go through the same strand. This is needed to -ensure thread safe access for any objects that are shared between the caller -and the composed operation (in the case of `async_read()` it's the socket, -which the caller can `close()` to cancel the operation). - -This is done by partially specialising the `asio::ssociated_executor<>` trait -for all intermediate handlers. This trait forwards to the corresponding trait -specialisation for the final handler: - - struct my_handler - { - void operator()() { ... } - }; - - namespace asio { - - template <class Executor> - struct associated_executor<my_handler, Executor> - { - // Custom implementation of Executor type requirements. - typedef my_executor type; - - // Return a custom executor implementation. - static type get(const my_handler&, const Executor& = Executor()) - { - return my_executor(); - } - }; - - } // namespace asio - -The `asio::bind_executor()` function is a helper to bind a specific executor -object, such as a strand, to a completion handler. This binding automatically -specialises the `associated_executor` trait as shown above. For example, to -bind a strand to a completion handler we would simply write: - - my_socket.async_read_some(my_buffer, - asio::bind_executor(my_strand, - [](error_code ec, size_t length) - { - // ... - })); - -[heading See Also] - -[link asio.reference.bind_executor bind_executor], -[link asio.reference.strand strand], -[link asio.reference.io_context__strand io_context::strand], -[link asio.tutorial.tuttimer5 tutorial Timer.5], -[link asio.examples.cpp03_examples.http_server_3 HTTP server 3 example]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/streams.qbk b/3rdparty/asio/src/doc/overview/streams.qbk deleted file mode 100644 index ea89e8b5d62..00000000000 --- a/3rdparty/asio/src/doc/overview/streams.qbk +++ /dev/null @@ -1,62 +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:streams Streams, Short Reads and Short Writes] - -Many I/O objects in Asio are stream-oriented. This means that: - -* There are no message boundaries. The data being transferred is a continuous - sequence of bytes. - -* Read or write operations may transfer fewer bytes than requested. This is - referred to as a short read or short write. - -Objects that provide stream-oriented I/O model one or more of the following -type requirements: - -* `SyncReadStream`, where synchronous read operations are performed using a - member function called `read_some()`. - -* `AsyncReadStream`, where asynchronous read operations are performed using a - member function called `async_read_some()`. - -* `SyncWriteStream`, where synchronous write operations are performed using a - member function called `write_some()`. - -* `AsyncWriteStream`, where synchronous write operations are performed using a - member function called `async_write_some()`. - -Examples of stream-oriented I/O objects include `ip::tcp::socket`, -`ssl::stream<>`, `posix::stream_descriptor`, `windows::stream_handle`, etc. - -Programs typically want to transfer an exact number of bytes. When a short read -or short write occurs the program must restart the operation, and continue to -do so until the required number of bytes has been transferred. Asio provides -generic functions that do this automatically: `read()`, `async_read()`, -`write()` and `async_write()`. - -[heading Why EOF is an Error] - -* The end of a stream can cause `read`, `async_read`, `read_until` or - `async_read_until` functions to violate their contract. E.g. - a read of N bytes may finish early due to EOF. - -* An EOF error may be used to distinguish the end of a stream from a successful - read of size 0. - -[heading See Also] - -[link asio.reference.async_read async_read()], -[link asio.reference.async_write async_write()], -[link asio.reference.read read()], -[link asio.reference.write write()], -[link asio.reference.AsyncReadStream AsyncReadStream], -[link asio.reference.AsyncWriteStream AsyncWriteStream], -[link asio.reference.SyncReadStream SyncReadStream], -[link asio.reference.SyncWriteStream SyncWriteStream]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/sync_op.dot b/3rdparty/asio/src/doc/overview/sync_op.dot deleted file mode 100644 index f3eb4dd4008..00000000000 --- a/3rdparty/asio/src/doc/overview/sync_op.dot +++ /dev/null @@ -1,67 +0,0 @@ -digraph g -{ - graph - [ - nodesep="0.6" - ]; - - edge - [ - fontname="Helvetica", - fontsize=10, - labelfontname="Helvetica", - labelfontsize=10 - ]; - - node - [ - fontname="Helvetica", - fontsize=10, - shape=box - ]; - - edge - [ - arrowhead="open" - ] - - // Program elements. - { - operating_system [ label="Operating System", shape=ellipse ]; - io_context [ label="io_context" ]; - io_object [ label="I/O Object\ne.g. socket" ]; - your_program [ label="Your Program" ]; - } - - // Owning relationships. - { - edge [ arrowtail="diamond" ]; - your_program:w -> io_object:nw; - your_program:se -> io_context:ne; - } - - // Non-owning relationships; - { - io_object:sw -> io_context:w; - } - - // Actions. - { - edge [ style="dashed", color="#808080" ]; - - // Forward actions. - { - your_program:sw -> io_object:n [ label="1" ]; - io_object:s -> io_context:nw [ label="2" ]; - io_context:sw -> operating_system:nw [ label="3" ]; - } - - // Reverse actions. - { - edge [ arrowhead="none", arrowtail="open" ]; - io_context:se -> operating_system:ne [ label="4" ]; - io_object:se -> io_context:n [ label="5" ]; - your_program:s -> io_object:ne [ label="6" ]; - } - } -} diff --git a/3rdparty/asio/src/doc/overview/sync_op.png b/3rdparty/asio/src/doc/overview/sync_op.png Binary files differdeleted file mode 100644 index a96c8351b9f..00000000000 --- a/3rdparty/asio/src/doc/overview/sync_op.png +++ /dev/null diff --git a/3rdparty/asio/src/doc/overview/threads.qbk b/3rdparty/asio/src/doc/overview/threads.qbk deleted file mode 100644 index b5239d9828e..00000000000 --- a/3rdparty/asio/src/doc/overview/threads.qbk +++ /dev/null @@ -1,66 +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:threads Threads and Asio] - -[heading Thread Safety] - -In general, it is safe to make concurrent use of distinct objects, but unsafe -to make concurrent use of a single object. However, types such as `io_context` -provide a stronger guarantee that it is safe to use a single object -concurrently. - -[heading Thread Pools] - -Multiple threads may call `io_context::run()` to set up a pool of threads from -which completion handlers may be invoked. This approach may also be used with -`io_context::post()` to use a means to perform any computational tasks across a -thread pool. - -Note that all threads that have joined an `io_context`'s pool are considered -equivalent, and the `io_context` may distribute work across them in an -arbitrary fashion. - -[heading Internal Threads] - -The implementation of this library for a particular platform may make use of -one or more internal threads to emulate asynchronicity. As far as possible, -these threads must be invisible to the library user. In particular, the threads: - -* must not call the user's code directly; and - -* must block all signals. - -This approach is complemented by the following guarantee: - -* Asynchronous completion handlers will only be called from threads that are - currently calling `io_context::run()`. - -Consequently, it is the library user's responsibility to create and manage all -threads to which the notifications will be delivered. - -The reasons for this approach include: - -* By only calling `io_context::run()` from a single thread, the user's code can - avoid the development complexity associated with synchronisation. For - example, a library user can implement scalable servers that are - single-threaded (from the user's point of view). - -* A library user may need to perform initialisation in a thread shortly after - the thread starts and before any other application code is executed. For - example, users of Microsoft's COM must call `CoInitializeEx` before any other - COM operations can be called from that thread. - -* The library interface is decoupled from interfaces for thread creation and - management, and permits implementations on platforms where threads are not - available. - -[heading See Also] - -[link asio.reference.io_context io_context]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/timers.qbk b/3rdparty/asio/src/doc/overview/timers.qbk deleted file mode 100644 index 0c5528dcc1b..00000000000 --- a/3rdparty/asio/src/doc/overview/timers.qbk +++ /dev/null @@ -1,52 +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:timers Timers] - -Long running I/O operations will often have a deadline by which they must have -completed. These deadlines may be expressed as absolute times, but are often -calculated relative to the current time. - -As a simple example, to perform a synchronous wait operation on a timer using a -relative time one may write: - - io_context i; - ... - deadline_timer t(i); - t.expires_from_now(boost::posix_time::seconds(5)); - t.wait(); - -More commonly, a program will perform an asynchronous wait operation on a -timer: - - void handler(asio::error_code ec) { ... } - ... - io_context i; - ... - deadline_timer t(i); - t.expires_from_now(boost::posix_time::milliseconds(400)); - t.async_wait(handler); - ... - i.run(); - -The deadline associated with a timer may also be obtained as a relative time: - - boost::posix_time::time_duration time_until_expiry - = t.expires_from_now(); - -or as an absolute time to allow composition of timers: - - deadline_timer t2(i); - t2.expires_at(t.expires_at() + boost::posix_time::seconds(30)); - -[heading See Also] - -[link asio.reference.basic_deadline_timer basic_deadline_timer], -[link asio.reference.deadline_timer deadline_timer], -[link asio.tutorial.tuttimer1 timer tutorials]. - -[endsect] diff --git a/3rdparty/asio/src/doc/overview/windows.qbk b/3rdparty/asio/src/doc/overview/windows.qbk deleted file mode 100644 index da49a0b409e..00000000000 --- a/3rdparty/asio/src/doc/overview/windows.qbk +++ /dev/null @@ -1,126 +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:windows Windows-Specific Functionality] - -[link asio.overview.windows.stream_handle Stream-Oriented HANDLEs] - -[link asio.overview.windows.random_access_handle Random-Access HANDLEs] - -[link asio.overview.windows.object_handle Object HANDLEs] - -[section:stream_handle Stream-Oriented HANDLEs] - -Asio contains classes to allow asynchronous read and write operations to be -performed on Windows `HANDLE`s, such as named pipes. - -For example, to perform asynchronous operations on a named pipe, the following -object may be created: - - HANDLE handle = ::CreateFile(...); - windows::stream_handle pipe(my_io_context, handle); - -These are then used as synchronous or asynchronous read and write streams. This -means the objects can be used with any of the [link asio.reference.read -read()], [link asio.reference.async_read async_read()], [link -asio.reference.write write()], [link asio.reference.async_write -async_write()], [link asio.reference.read_until read_until()] or [link -asio.reference.async_read_until async_read_until()] free functions. - -The kernel object referred to by the `HANDLE` must support use with I/O -completion ports (which means that named pipes are supported, but anonymous -pipes and console streams are not). - -[heading See Also] - -[link asio.reference.windows__stream_handle windows::stream_handle]. - -[heading Notes] - -Windows stream `HANDLE`s are only available at compile time when targeting -Windows and only when the I/O completion port backend is used (which is the -default). A program may test for the macro `ASIO_HAS_WINDOWS_STREAM_HANDLE` to -determine whether they are supported. - -[endsect] - -[/-----------------------------------------------------------------------------] - -[section:random_access_handle Random-Access HANDLEs] - -Asio provides Windows-specific classes that permit asynchronous read and write -operations to be performed on HANDLEs that refer to regular files. - -For example, to perform asynchronous operations on a file the following object -may be created: - - HANDLE handle = ::CreateFile(...); - windows::random_access_handle file(my_io_context, handle); - -Data may be read from or written to the handle using one of the -`read_some_at()`, `async_read_some_at()`, `write_some_at()` or -`async_write_some_at()` member functions. However, like the equivalent -functions (`read_some()`, etc.) on streams, these functions are only required -to transfer one or more bytes in a single operation. Therefore free functions -called [link asio.reference.read_at read_at()], [link -asio.reference.async_read_at async_read_at()], [link asio.reference.write_at -write_at()] and [link asio.reference.async_write_at async_write_at()] have been -created to repeatedly call the corresponding [^[**]_some_at()] function until -all data has been transferred. - -[heading See Also] - -[link asio.reference.windows__random_access_handle windows::random_access_handle]. - -[heading Notes] - -Windows random-access `HANDLE`s are only available at compile time when -targeting Windows and only when the I/O completion port backend is used (which -is the default). A program may test for the macro -`ASIO_HAS_WINDOWS_RANDOM_ACCESS_HANDLE` to determine whether they are -supported. - -[endsect] - -[/-----------------------------------------------------------------------------] - -[section:object_handle Object HANDLEs] - -Asio provides Windows-specific classes that permit asynchronous wait operations -to be performed on HANDLEs to kernel objects of the following types: - -* Change notification -* Console input -* Event -* Memory resource notification -* Process -* Semaphore -* Thread -* Waitable timer - -For example, to perform asynchronous operations on an event, the following -object may be created: - - HANDLE handle = ::CreateEvent(...); - windows::object_handle file(my_io_context, handle); - -The `wait()` and `async_wait()` member functions may then be used to wait until -the kernel object is signalled. - -[heading See Also] - -[link asio.reference.windows__object_handle windows::object_handle]. - -[heading Notes] - -Windows object `HANDLE`s are only available at compile time when targeting -Windows. Programs may test for the macro `ASIO_HAS_WINDOWS_OBJECT_HANDLE` to -determine whether they are supported. - -[endsect] - -[endsect] |