]> git.proxmox.com Git - ceph.git/blobdiff - ceph/src/boost/libs/asio/example/cpp03/tutorial/timer_dox.txt
update sources to v12.2.3
[ceph.git] / ceph / src / boost / libs / asio / example / cpp03 / tutorial / timer_dox.txt
index 6553f39a777eb524a90b4da75ea3c256e69c845c..32e29982e5059e4b085037157c0efa335d40b357 100644 (file)
@@ -1,5 +1,5 @@
 //
-// Copyright (c) 2003-2016 Christopher M. Kohlhoff (chris at kohlhoff dot com)
+// Copyright (c) 2003-2017 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)
@@ -292,8 +292,8 @@ Return to \ref tuttimer4
 /**
 \page tuttimer5 Timer.5 - Synchronising handlers in multithreaded programs
 
-This tutorial demonstrates the use of the boost::asio::strand class to synchronise
-callback handlers in a multithreaded program.
+This tutorial demonstrates the use of the boost::asio::io_service::strand class to
+synchronise callback handlers in a multithreaded program.
 
 The previous four tutorials avoided the issue of handler synchronisation by
 calling the boost::asio::io_service::run() function from one thread only. As you
@@ -329,22 +329,25 @@ tutorial by running two timers in parallel.
 
 In addition to initialising a pair of boost::asio::deadline_timer members, the
 constructor initialises the <tt>strand_</tt> member, an object of type
-boost::asio::strand.
+boost::asio::io_service::strand.
 
-An boost::asio::strand guarantees that, for those handlers that are dispatched through
-it, an executing handler will be allowed to complete before the next one is
-started. This is guaranteed irrespective of the number of threads that are
-calling boost::asio::io_service::run(). Of course, the handlers may still execute
-concurrently with other handlers that were <b>not</b> dispatched through an
-boost::asio::strand, or were dispatched through a different boost::asio::strand object.
+An boost::asio::io_service::strand is an executor that guarantees that, for those
+handlers that are dispatched through it, an executing handler will be allowed
+to complete before the next one is started. This is guaranteed irrespective of
+the number of threads that are calling boost::asio::io_service::run(). Of course, the
+handlers may still execute concurrently with other handlers that were
+<b>not</b> dispatched through an boost::asio::io_service::strand, or were dispatched
+through a different boost::asio::io_service::strand object.
 
 \until {
 
-When initiating the asynchronous operations, each callback handler is "wrapped"
-using the boost::asio::strand object. The boost::asio::strand::wrap() function returns a new
-handler that automatically dispatches its contained handler through the
-boost::asio::strand object. By wrapping the handlers using the same boost::asio::strand, we
-are ensuring that they cannot execute concurrently.
+When initiating the asynchronous operations, each callback handler is "bound"
+to an boost::asio::io_service::strand object. The
+boost::asio::io_service::strand::bind_executor() function returns a new handler that
+automatically dispatches its contained handler through the
+boost::asio::io_service::strand object. By binding the handlers to the same
+boost::asio::io_service::strand, we are ensuring that they cannot execute
+concurrently.
 
 \until }
 \until }