RubyGems - couchbase - Versions diffs - 3.0.0.alpha.3-universal-darwin-19 → 3.0.1-universal-darwin-19 - Mend

couchbase 3.0.0.alpha.3-universal-darwin-19 → 3.0.1-universal-darwin-19

Files changed (1684) hide show

data/ext/third_party/asio/asio/src/doc/overview/proactor.png DELETED

Binary file

data/ext/third_party/asio/asio/src/doc/overview/protocols.qbk DELETED

@@ -1,149 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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]

data/ext/third_party/asio/asio/src/doc/overview/rationale.qbk DELETED

@@ -1,54 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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]

data/ext/third_party/asio/asio/src/doc/overview/reactor.qbk DELETED

@@ -1,44 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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]

data/ext/third_party/asio/asio/src/doc/overview/serial_ports.qbk DELETED

@@ -1,45 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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]

data/ext/third_party/asio/asio/src/doc/overview/signals.qbk DELETED

@@ -1,44 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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]

data/ext/third_party/asio/asio/src/doc/overview/spawn.qbk DELETED

@@ -1,102 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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]

data/ext/third_party/asio/asio/src/doc/overview/ssl.qbk DELETED

@@ -1,124 +0,0 @@
-[/
- / Copyright (c) 2003-2020 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 6125 (identity verification in the context of Transport Layer Security),
-Asio provides a reusable verification callback as a function object:
-* [link asio.reference.ssl__host_name_verification ssl::host_name_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::host_name_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__host_name_verification ssl::host_name_verification],
-[link asio.reference.ssl__stream ssl::stream],
-[link asio.examples.cpp03_examples.ssl SSL example (C++03)],
-[link asio.examples.cpp11_examples.ssl SSL example (C++11)].
-[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]