Removing/replacing use of Boost deprecated APIs removed between 1.84 and 1.87.

Author: ygoldfeld

src/flow/async/async_fwd.hpp

@@ -38,8 +38,8 @@
  * certain advanced features as mentioned above.
  *
  *   - boost.asio provides the core algorithmic abilities of an optionally multi-threaded task-executing loop,
- *     particularly through classes util::Task_engine (a/k/a `boost::asio::io_service`), util::Strand
- *     (a/k/a `boost::asio::io_service::strand`), and util::Timer.  flow::async Flow module somewhat streamlines
+ *     particularly through classes util::Task_engine (a/k/a `boost::asio::io_context`), util::Strand
+ *     (a/k/a `strand` in `boost::asio`), and util::Timer.  flow::async Flow module somewhat streamlines
  *     this API in such a way as to keep the user's focus on their conceptual async-task-driven algorithm as opposed
  *     to details of threads, handlers, cores, etc.  The async::Op opaque type is central to this streamlined API,
  *     plus the central class Concurrent_task_loop.
@@ -177,7 +177,7 @@ using Task_asio_err = Function<void (const Error_code&)>;
 using Task_asio_err_sz = Function<void (const Error_code&, size_t)>;
 
 /**
- * Short-hand for reference-counting pointer to a mutable util::Task_engine (a/k/a `boost::asio::io_service`).
+ * Short-hand for reference-counting pointer to a mutable util::Task_engine (a/k/a `boost::asio::io_context`).
  * This is generally how classes in the Concurrent_task_loop hierarchy refer to their internally used
  * `Task_engine`s but also in advanced cases may be communicated to their user.
  *

src/flow/async/concurrent_task_loop.hpp

@@ -622,7 +622,7 @@ class Concurrent_task_loop :
                                                   const Fine_time_pt& at, Scheduled_task&& task) = 0;
 
   /**
-   * Returns a pointer to *an* internal util::Task_engine (a/k/a boost.asio `io_service`) for the purpose of
+   * Returns a pointer to *an* internal util::Task_engine (a/k/a boost.asio `io_context`) for the purpose of
    * performing a boost.asio `async_*()` action on some boost.asio I/O object in the immediate near future.
    *
    * The mechanics of using this are explained in Concurrent_task_loop doc header.  Using this in any other

src/flow/async/detail/task_qing_thread.hpp

@@ -30,7 +30,7 @@ namespace flow::async
 
 /**
  * Internally used building block of various concrete Concurrent_task_loop subclasses that encapsulates a thread
- * that spawns at construction time and a dedicated-or-shared util::Task_engine (a/k/a boost.asio `io_service`)
+ * that spawns at construction time and a dedicated-or-shared util::Task_engine (a/k/a boost.asio `io_context`)
  * `run()`ning in that new thread.
  *
  * This class:

src/flow/async/segregated_thread_task_loop.hpp

@@ -293,7 +293,7 @@ class Segregated_thread_task_loop :
   std::vector<Task_qing_thread_ptr> m_qing_threads;
 
   /**
-   * boost.asio `Task_engine`s (a/k/a `io_service`s) used by each respective element in #m_qing_threads.
+   * boost.asio `Task_engine`s (a/k/a `io_context`s) used by each respective element in #m_qing_threads.
    * It is critical that this not be modified after constructor returns, for the same thread safety reason mentioned
    * in the warning in #m_qing_threads doc header.
    */

src/flow/async/single_thread_task_loop.hpp

@@ -241,7 +241,7 @@ class Single_thread_task_loop :
   virtual util::Scheduled_task_handle schedule_at(const Fine_time_pt& at, Scheduled_task&& task);
 
   /**
-   * Returns a pointer to *the* internal util::Task_engine (a/k/a boost.asio `io_service`) for the purpose of
+   * Returns a pointer to *the* internal util::Task_engine (a/k/a boost.asio `io_context`) for the purpose of
    * performing a boost.asio `async_*()` action on some boost.asio I/O object in the immediate near future.
    *
    * @return A mutable util::Task_engine to use soon.  It is *allowed* to use it as long as

src/flow/async/x_thread_task_loop.hpp

@@ -297,7 +297,7 @@ class Cross_thread_task_loop :
   /// N task-execution-capable worker threads whose lifetimes equal those of `*this`, all sharing #m_shared_task_engine.
   std::vector<Task_qing_thread_ptr> m_qing_threads;
 
-  /// boost.asio `Task_engine` (a/k/a `io_service`) co-used by all #m_qing_threads.
+  /// boost.asio `Task_engine` (a/k/a `io_context`) co-used by all #m_qing_threads.
   Task_engine_ptr m_shared_task_engine;
 
   /// See per_thread_ops().  The `boost::any` payload is always of the type async::Strand_ptr.

src/flow/log/async_file_logger.cpp

@@ -89,7 +89,7 @@ Async_file_logger::Async_file_logger(Logger* backup_logger_ptr,
     /* this->impl_log_flush_and_reopen() will be called on signal (or error).
      * Note that that function's contract (from its doc comment) is it must execute in m_async_worker (see
      * m_signal_set() init above in the init section of ctor).
-     * Indeed boost::asio::io_service semantics guarantee it'll run in m_async_worker (not some
+     * Indeed boost::asio::io_context semantics guarantee it'll run in m_async_worker (not some
      * no-man's-land signal handler thread of execution, as one might fear could be the case) for the same reason
      * the various post()ed tasks will run in m_async_worker. */
     m_signal_set.async_wait([this](const Error_code& sys_err_code, int sig_number)

src/flow/net_flow/asio/node.hpp

@@ -35,7 +35,7 @@ namespace flow::net_flow::asio
  * directly in a boost.asio event loop (see reference below for background).  It is possible to use the
  * vanilla net_flow::Node, etc., with *any* asynchronous event loop (boost.asio or native `epoll` or `select()`...) --
  * notably by using a glue socket, as explained in Event_set doc header.  However, for those using the boost.asio
- * `io_service` as the app's core main loop, this is not as easy as what one might desire.  (Side note:
+ * `io_context` as the app's core main loop, this is not as easy as what one might desire.  (Side note:
  * I personally strongly recommend using boost.asio event loops instead of rolling one's own or the many alternatives
  * I have seen.  It is also on its way to ending up in the C++ standard library.  Lastly, such a loop is used
  * internally to implement `net_flow`, so you know I like it, for what that's worth.)
@@ -46,7 +46,7 @@ namespace flow::net_flow::asio
  *
  * The usage pattern is simple, assuming you understand tha basics of net_flow::Node, net_flow::Server_socket, and
  * net_flow::Peer_socket -- and especially if you are familiar with boost.asio's built-in `tcp::acceptor` and
- * `tcp::socket` (and, of course, `boost::asio::io_service` that ties them and many more I/O objects together).
+ * `tcp::socket` (and, of course, `boost::asio::io_context` that ties them and many more I/O objects together).
  *
  *   - First, simply create an asio::Node using the same form of constructor as you would with net_flow::Node, plus
  *     an arg that's a pointer to the subsequently used target boost.asio flow::util::Task_engine, which is memorized.
@@ -72,7 +72,7 @@ namespace flow::net_flow::asio
  *       - For each op inside an "arrow," I mean to include all forms of it
  *         (`F` includes: `F()`, `sync_F()`, `async_F()`).
  *       - This pattern is more practical/reasonable for us than the boost.asio pattern of each object memorizing its
- *         `io_service` reference in its explicit constructor.  That is because we fully embrace the
+ *         `io_context` reference in its explicit constructor.  That is because we fully embrace the
  *         factory-of-shared-pointers pattern, and boost.asio doesn't use that pattern.  We also provide an explicit
  *         mutator however.
  *       - We also allow for a null `Task_engine*` -- except when `async_*()` is actually performed.
@@ -82,7 +82,7 @@ namespace flow::net_flow::asio
  *         boost.asio built-in I/O objects.)
  *
  * Having thus obtained asio::Server_socket and asio::Peer_socket objects (and assigned each their desired
- * boost.asio `io_service` loop(s) -- essentially as one does with, e.g., `tcp::acceptor` and `tcp::socket`
+ * boost.asio `io_context` loop(s) -- essentially as one does with, e.g., `tcp::acceptor` and `tcp::socket`
  * respectively) -- you many now use the full range of I/O operations.  Here is a bird's eye view of all operations
  * available in the entire hierarchy.  Note that conceptually this is essentially identical to boost.asio `tcp`
  * I/O objects, but nomenclature and API decisions are in some cases somewhat different (I contend: with good reason).
@@ -130,25 +130,25 @@ namespace flow::net_flow::asio
  *   - Asynchronous operations (`asio::*` classes provide these):
  *     - asio::Server_socket::async_accept() -> asio::Peer_socket: Obtain a fully connected peer socket object,
  *       waiting as necessary in background for a connection to come in and fully establish,
- *       then invoking user-provided callback as if by `io_service::post()`.
+ *       then invoking user-provided callback as if by `io_context::post()`.
  *       - Equivalent: `tcp::acceptor::async_accept()`.
  *       - Variations: optional timeout can be specified.
  *       - Variations: `reactor_pattern` mode, where the `accept()` call itself is left to user handler.
  *     - asio::Node::async_connect() -> net_flow::Peer_socket: Return a fully connected peer socket object,
  *       waiting as necessary in background to reach the remote server and fully establish connection,
- *       then invoking user-provided callback as if by `io_service::post()`.
+ *       then invoking user-provided callback as if by `io_context::post()`.
  *       - Equivalent: `tcp::socket::async_connect()`.
  *       - Variations: optional timeout can be specified.
  *       - Variations: see also `*_with_metadata()` as above.
  *     - asio::Peer_socket::async_send(): Queue up at least 1 of the N given bytes to send to peer ASAP,
  *       waiting as necessary in background for this to become possible (as explained above),
- *       then invoking user-provided callback as if by `io_service::post()`.
+ *       then invoking user-provided callback as if by `io_context::post()`.
  *       - Equivalent: `tcp::socket::async_send()`.
  *       - Variations: optional timeout can be specified.
  *       - Variations: `null_buffers` mode, where the `send()` call itself is left to user handler.
  *     - asio::Peer_socket::async_receive(): Dequeue at least 1 of the desired N bytes from peer,
  *       waiting as necessary in background for this to arrive from said remote peer,
- *       then invoking user-provided callback as if by `io_service::post()`.
+ *       then invoking user-provided callback as if by `io_context::post()`.
  *       - Equivalent: `tcp::socket::async_receive()`.
  *       - Variations: optional timeout can be specified.
  *       - Variations: `null_buffers` mode, where the `receive()` call itself is left to user handler.
@@ -169,7 +169,7 @@ namespace flow::net_flow::asio
  *       - Equivalent: `poll()` with 0 timeout.
  *     - Event_set::async_wait(): Asynchronous I/O multiplixing, like sync_wait() but waits in background and
  *       executes user-provided callback from an unspecified thread.  (A typical callback might set a `future`
- *       result; `io_service::post()` a task to some boost.asio event loop; perhaps set a flag that is
+ *       result; `io_context::post()` a task to some boost.asio event loop; perhaps set a flag that is
  *       periodically checked by some user thread; or send a byte over some quick IPC mechanism like a POSIX
  *       domain socket or loopback UDP socket -- or even a condition variable.)
  *       - Equivalents: none in POSIX, that I know of.  Windows "overlapped" async I/O sounds vaguely like a distant

src/flow/net_flow/asio/peer_socket.hpp

@@ -28,10 +28,10 @@ namespace flow::net_flow::asio
  * A net_flow::Peer_socket that adds integration with boost.asio.  See net_flow::Node for a discussion of the topic of
  * boost.asio integration.  A net_flow::asio::Peer_socket *is* a net_flow::Peer_socket with all that functionality, plus
  * APIs (such as async_send(), async_receive()) that accomplish boost.asio-style asynchronous operations with a
- * standard `boost::asio::io_service` (a/k/a flow::util::Task_engine).
+ * standard `boost::asio::io_context` (a/k/a flow::util::Task_engine).
  *
  * As of this writing, `asio::Peer_socket::Ptr`s are generated by `asio::Node::connect()`,
- * `asio::Server_socket::accept()`, and their derivatives.  The underlying `io_service` (a/k/a flow::util::Task_engine)
+ * `asio::Server_socket::accept()`, and their derivatives.  The underlying `io_context` (a/k/a flow::util::Task_engine)
  * is carried forward from the factory object that generated and returned the `Ptr`.  It can be overwritten via
  * set_async_task_engine().
  */

src/flow/net_flow/asio/server_socket.hpp

@@ -28,10 +28,10 @@ namespace flow::net_flow::asio
  * A net_flow::Server_socket that adds integration with boost.asio.  See net_flow::Node for a discussion of the topic of
  * boost.asio integration.  A net_flow::asio::Server_socket *is* a net_flow::Server_socket with all that functionality,
  * plus APIs (mainly async_accept()) that accomplish boost.asio-style asynchronous operations with a
- * standard `boost::asio::io_service`.
+ * standard `boost::asio::io_context`.
  *
  * As of this writing, `asio::Server_socket::Ptr`s are generated by `net_flow::Node::listen()` and any derivatives.
- * The underlying `io_service` (a/k/a flow::util::Task_engine)
+ * The underlying `io_context` (a/k/a flow::util::Task_engine)
  * is carried forward from the `net_flow::asio::Node` factory object that generated and returned the `Ptr`.  It can be
  * overwritten via set_async_task_engine().
  */