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

data/ext/third_party/asio/asio/src/doc/noncopyable_dox.txt

@@ -1,3 +0,0 @@
-/**
-\class noncopyable
-*/

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

@@ -1,103 +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:overview Overview]
-
-* [link asio.overview.rationale Rationale]
-* [link asio.overview.core Core Concepts and Functionality]
-  * [link asio.overview.core.basics Basic Asio Anatomy]
-  * [link asio.overview.core.async The Proactor Design Pattern: Concurrency Without Threads]
-  * [link asio.overview.core.threads Threads and Asio]
-  * [link asio.overview.core.strands Strands: Use Threads Without Explicit Locking]
-  * [link asio.overview.core.buffers Buffers]
-  * [link asio.overview.core.streams Streams, Short Reads and Short Writes]
-  * [link asio.overview.core.reactor Reactor-Style Operations]
-  * [link asio.overview.core.line_based Line-Based Operations]
-  * [link asio.overview.core.allocation Custom Memory Allocation]
-  * [link asio.overview.core.handler_tracking Handler Tracking]
-  * [link asio.overview.core.concurrency_hint Concurrency Hints]
-  * [link asio.overview.core.coroutine Stackless Coroutines]
-  * [link asio.overview.core.spawn Stackful Coroutines]
-  * [link asio.overview.core.coroutines_ts Coroutines TS Support]
-* [link asio.overview.networking Networking]
-  * [link asio.overview.networking.protocols TCP, UDP and ICMP]
-  * [link asio.overview.networking.other_protocols Support for Other Protocols]
-  * [link asio.overview.networking.iostreams Socket Iostreams]
-  * [link asio.overview.networking.bsd_sockets The BSD Socket API and Asio]
-* [link asio.overview.timers Timers]
-* [link asio.overview.serial_ports Serial Ports]
-* [link asio.overview.signals Signal Handling]
-* [link asio.overview.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.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.ssl SSL]
-* [link asio.overview.cpp2011 C++ 2011 Support]
-* [link asio.overview.implementation Platform-Specific Implementation Notes]
-
-[include overview/rationale.qbk]
-
-[section:core Core Concepts and Functionality]
-
-* [link asio.overview.core.basics Basic Asio Anatomy]
-* [link asio.overview.core.async The Proactor Design Pattern: Concurrency Without Threads]
-* [link asio.overview.core.threads Threads and Asio]
-* [link asio.overview.core.strands Strands: Use Threads Without Explicit Locking]
-* [link asio.overview.core.buffers Buffers]
-* [link asio.overview.core.streams Streams, Short Reads and Short Writes]
-* [link asio.overview.core.reactor Reactor-Style Operations]
-* [link asio.overview.core.line_based Line-Based Operations]
-* [link asio.overview.core.allocation Custom Memory Allocation]
-* [link asio.overview.core.handler_tracking Handler Tracking]
-* [link asio.overview.core.concurrency_hint Concurrency Hints]
-* [link asio.overview.core.coroutine Stackless Coroutines]
-* [link asio.overview.core.spawn Stackful Coroutines]
-* [link asio.overview.core.coroutines_ts Coroutines TS Support]
-
-[include overview/basics.qbk]
-[include overview/async.qbk]
-[include overview/threads.qbk]
-[include overview/strands.qbk]
-[include overview/buffers.qbk]
-[include overview/streams.qbk]
-[include overview/reactor.qbk]
-[include overview/line_based.qbk]
-[include overview/allocation.qbk]
-[include overview/handler_tracking.qbk]
-[include overview/concurrency_hint.qbk]
-[include overview/coroutine.qbk]
-[include overview/spawn.qbk]
-[include overview/coroutines_ts.qbk]
-
-[endsect]
-
-[section:networking Networking]
-
-* [link asio.overview.networking.protocols TCP, UDP and ICMP]
-* [link asio.overview.networking.other_protocols Support for Other Protocols]
-* [link asio.overview.networking.iostreams Socket Iostreams]
-* [link asio.overview.networking.bsd_sockets The BSD Socket API and Asio]
-
-[include overview/protocols.qbk]
-[include overview/other_protocols.qbk]
-[include overview/iostreams.qbk]
-[include overview/bsd_sockets.qbk]
-
-[endsect]
-
-[include overview/timers.qbk]
-[include overview/serial_ports.qbk]
-[include overview/signals.qbk]
-[include overview/posix.qbk]
-[include overview/windows.qbk]
-[include overview/ssl.qbk]
-[include overview/cpp2011.qbk]
-[include overview/implementation.qbk]
-
-[endsect]

data/ext/third_party/asio/asio/src/doc/overview/allocation.qbk

@@ -1,89 +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: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 obtain an
-allocator using the `get_associated_allocator` function. For example:
-
-  asio::associated_allocator_t<Handler> a = asio::get_associated_allocator(h);
-
-The associated allocator must satisfy the standard Allocator requirements.
-
-By default, handlers use the standard allocator (which is implemented in terms
-of `::operator new()` and `::operator delete()`). The allocator may be
-customised for a particular handler type by specifying a nested type
-`allocator_type` and member function `get_allocator()`:
-
-  class my_handler
-  {
-  public:
-    // Custom implementation of Allocator type requirements.
-    typedef my_allocator allocator_type;
-
-    // Return a custom allocator implementation.
-    allocator_type get_allocator() const noexcept
-    {
-      return my_allocator();
-    }
-
-    void operator()() { ... }
-  };
-
-In more complex cases, the `associated_allocator` template may be partially
-specialised directly:
-
-  namespace asio {
-
-    template <typename Allocator>
-    struct associated_allocator<my_handler, Allocator>
-    {
-      // Custom implementation of Allocator type requirements.
-      typedef my_allocator type;
-
-      // Return a custom allocator implementation.
-      static type get(const my_handler&,
-          const Allocator& a = Allocator()) noexcept
-      {
-        return my_allocator();
-      }
-    };
-
-  } // namespace asio
-
-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.associated_allocator associated_allocator],
-[link asio.reference.get_associated_allocator get_associated_allocator],
-[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]

data/ext/third_party/asio/asio/src/doc/overview/async.qbk

@@ -1,185 +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: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]

data/ext/third_party/asio/asio/src/doc/overview/async_op1.dot

@@ -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" ];
-    }
-  }
-}