boost/asio
2
0
Fork 0
mirror of https://github.com/boostorg/asio.git synced 2026-01-28 06:42:08 +00:00
Code Issues Projects Releases Wiki Activity
Files
603397befbddda72782cb8e137482851f1c3f069
asio/example/cpp03/tutorial/timer_dox.txt
Christopher Kohlhoff 603397befb Merge from trunk. 
------------------------------------------------------------------------
r84301 | chris_kohlhoff | 2013-05-17 07:34:54 +1000 (Fri, 17 May 2013) | 2 lines

Enable handler type requirements static_assert on clang.

------------------------------------------------------------------------
r84308 | chris_kohlhoff | 2013-05-17 09:26:04 +1000 (Fri, 17 May 2013) | 3 lines

Add new traits classes, handler_type and async_result, that allow
the customisation of the return type of an initiating function.

------------------------------------------------------------------------
r84311 | chris_kohlhoff | 2013-05-17 11:38:47 +1000 (Fri, 17 May 2013) | 81 lines

Add the asio::spawn() function, a high-level wrapper for running
stackful coroutines. It is based on the Boost.Coroutine library.

Here is an example of its use:

  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 asio::spawn() may be a strand, io_service or
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 a completion handler signature has the form:

  void handler(error_code ec, result_type result);

the initiating function returns the result_type. In the async_read_some
example above, this is std::size_t. If the asynchronous operation fails,
the error_code is converted into a system_error exception and thrown.

Where a completion handler signature has the form:

  void handler(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:

  error_code ec;
  std::size_t length =
    my_socket.async_read_some(
      asio::buffer(data), yield[ec]);

**Note: if asio::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);

------------------------------------------------------------------------
r84312 | chris_kohlhoff | 2013-05-17 12:25:10 +1000 (Fri, 17 May 2013) | 4 lines

Move existing examples into a C++03-specific directory, and add a new
directory for C++11-specific examples. A limited subset of the C++03
examples have been converted to their C++11 equivalents.

------------------------------------------------------------------------
r84313 | chris_kohlhoff | 2013-05-17 12:35:08 +1000 (Fri, 17 May 2013) | 26 lines

Add the asio::use_future special value, which adds 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 completion handler signature has the form:

  void handler(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 completion handler signature has the form:

  void handler(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.

------------------------------------------------------------------------
r84314 | chris_kohlhoff | 2013-05-17 13:07:51 +1000 (Fri, 17 May 2013) | 27 lines

Add a new handler hook called asio_handler_is_continuation.

Asynchronous operations may represent a continuation of the asynchronous
control flow associated with the current handler. Asio's implementation
can use this knowledge to optimise scheduling of the handler.

The asio_handler_is_continuation hook returns true to indicate whether a
completion handler represents a continuation of the current call
context. The default implementation of the hook returns false, and
applications may customise the hook when necessary. The hook has already
been customised within Asio to return true for the following cases:

- Handlers returned by strand.wrap(), when the corresponding
  asynchronous operation is being initiated from within the strand.

- The internal handlers used to implement the asio::spawn() function's
  stackful coroutines.

- When an intermediate handler of a composed operation (e.g.
  asio::async_read(), asio::async_write(), asio::async_connect(),
  ssl::stream<>, etc.) starts a new asynchronous operation due to the
  composed operation not being complete.

To support this optimisation, a new running_in_this_thread() member
function has been added to the io_service::strand class. This function
returns true when called from within a strand.

------------------------------------------------------------------------
r84315 | chris_kohlhoff | 2013-05-17 20:06:50 +1000 (Fri, 17 May 2013) | 3 lines

Partially decouple Asio from other boost components via an extra level
of indirection.

------------------------------------------------------------------------
r84316 | chris_kohlhoff | 2013-05-17 20:15:21 +1000 (Fri, 17 May 2013) | 2 lines

Minor cleanup.

------------------------------------------------------------------------
r84319 | chris_kohlhoff | 2013-05-17 20:52:08 +1000 (Fri, 17 May 2013) | 9 lines

Support handshake with re-use of data already read from the wire.

Add new overloads of the SSL stream's handshake() and async_handshake()
functions, that accepts a ConstBufferSequence to be used as initial
input to the ssl engine for the handshake procedure.

Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is partially based.

------------------------------------------------------------------------
r84320 | chris_kohlhoff | 2013-05-17 20:57:02 +1000 (Fri, 17 May 2013) | 6 lines

Support for creation of TLSv1.1 and TLSv1.2 contexts.

Thanks go to Alvin Cheung <alvin dot cheung at alumni dot ust dot hk>
and Nick Jones <nick dot fa dot jones at gmail dot com>, on whose work
this is based.

------------------------------------------------------------------------
r84322 | chris_kohlhoff | 2013-05-17 21:00:49 +1000 (Fri, 17 May 2013) | 5 lines

Add set_verify_depth function to SSL context and stream.

Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is based.

------------------------------------------------------------------------
r84325 | chris_kohlhoff | 2013-05-17 21:04:11 +1000 (Fri, 17 May 2013) | 9 lines

Allow loading of SSL certificate and key data from memory buffers.

Added new buffer-based interfaces:
add_certificate_authority, use_certificate, use_certificate_chain,
use_private_key, use_rsa_private_key, use_tmp_dh.

Thanks go to Nick Jones <nick dot fa dot jones at gmail dot com>, on
whose work this commit is based.

------------------------------------------------------------------------
r84345 | chris_kohlhoff | 2013-05-18 21:24:59 +1000 (Sat, 18 May 2013) | 2 lines

Update copyright notices.

------------------------------------------------------------------------
r84346 | chris_kohlhoff | 2013-05-18 21:54:59 +1000 (Sat, 18 May 2013) | 3 lines

Remove the stackless coroutine class and macros from the HTTP server 4
example, and instead make them a part of Asio's documented interface.

------------------------------------------------------------------------
r84347 | chris_kohlhoff | 2013-05-18 22:01:59 +1000 (Sat, 18 May 2013) | 4 lines

Fix basic_waitable_timer's underlying implementation so that it can
handle any time_point value without overflowing the intermediate
duration objects.

------------------------------------------------------------------------
r84348 | chris_kohlhoff | 2013-05-18 22:07:00 +1000 (Sat, 18 May 2013) | 3 lines

Fix a problem with lost thread wakeups that can occur when making
concurrent calls to run() and poll() on the same io_service object.

------------------------------------------------------------------------
r84349 | chris_kohlhoff | 2013-05-18 22:13:17 +1000 (Sat, 18 May 2013) | 3 lines

Fix implementation of asynchronous connect operation so that it can cope
with spurious readiness notifications from the reactor.

------------------------------------------------------------------------
r84361 | chris_kohlhoff | 2013-05-19 07:56:31 +1000 (Sun, 19 May 2013) | 1 line

Remove some trailing spaces and fix another copyright notice.

------------------------------------------------------------------------
r84363 | chris_kohlhoff | 2013-05-19 14:55:11 +1000 (Sun, 19 May 2013) | 53 lines

Add generic socket protocols and converting move constructors.

Four new protocol classes have been added:

- asio::generic::datagram_protocol
- asio::generic::raw_protocol
- asio::generic::seq_packet_protocol
- asio::generic::stream_protocol

These classes implement the 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.

A new endpoint class template, asio::generic::basic_endpoint, has been
added to support these new protocol classes. This endpoint can hold any
other endpoint type, provided its native representation fits into a
sockaddr_storage object.

When using C++11, it is now 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 socket1(io_service);
  ...
  Protocol2::socket socket2(std::move(socket1));

For example, one possible conversion is from a TCP socket to a generic
stream-oriented socket:

  asio::ip::tcp::socket socket1(io_service);
  ...
  asio::generic::stream_protocol::socket socket2(std::move(socket1));

The conversion is also available for move-assignment. Note that these
conversions are not limited to the newly added 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.

As a convenience, the socket acceptor's accept() and async_accept()
functions have been changed so that they can directly accept into a
different protocol's socket type, provided the protocol conversion is
valid. For example, the following is now possible:

  asio::ip::tcp::acceptor acceptor(io_service);
  ...
  asio::generic::stream_protocol::socket socket1(io_service);
  acceptor.accept(socket1);


[SVN r84388]
2013-05-20 12:32:20 +00:00

381 lines
13 KiB
Plaintext
Raw Blame History

//
// Copyright (c) 2003-2013 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)
//
/**
\page tuttimer1 Timer.1 - Using a timer synchronously
This tutorial program introduces asio by showing how to perform a blocking
wait on a timer.
\dontinclude timer1/timer.cpp
\skip #include
We start by including the necessary header files.
All of the asio classes can be used by simply including the <tt>"asio.hpp"</tt>
header file.
\until asio.hpp
Since this example uses timers, we need to include the appropriate
Boost.Date_Time header file for manipulating times.
\until posix_time.hpp
All programs that use asio need to have at least one boost::asio::io_service object.
This class provides access to I/O functionality. We declare an object of this
type first thing in the main function.
\until boost::asio::io_service
Next we declare an object of type boost::asio::deadline_timer. The core asio classes
that provide I/O functionality (or as in this case timer functionality) always
take a reference to an io_service as their first constructor argument. The
second argument to the constructor sets the timer to expire 5 seconds from now.
\until boost::asio::deadline_timer
In this simple example we perform a blocking wait on the timer.
That is, the call to boost::asio::deadline_timer::wait() will not return until the
timer has expired, 5 seconds after it was created (i.e. <b>not</b> from when the
wait starts).
A deadline timer is always in one of two states: "expired" or "not expired". If
the boost::asio::deadline_timer::wait() function is called on an expired timer, it
will return immediately.
\until wait
Finally we print the obligatory <tt>"Hello, world!"</tt>
message to show when the timer has expired.
\until }
See the \ref tuttimer1src "full source listing" \n
Return to the \ref index "tutorial index" \n
Next: \ref tuttimer2
*/
/**
\page tuttimer1src Source listing for Timer.1
\include timer1/timer.cpp
Return to \ref tuttimer1
*/
/**
\page tuttimer2 Timer.2 - Using a timer asynchronously
This tutorial program demonstrates how to use asio's asynchronous callback
functionality by modifying the program from tutorial Timer.1 to perform an
asynchronous wait on the timer.
\dontinclude timer2/timer.cpp
\skip #include
\until posix_time.hpp
Using asio's asynchronous functionality means having a callback
function that will be called when an asynchronous operation completes. In this
program we define a function called <tt>print</tt> to be called when the
asynchronous wait finishes.
\until boost::asio::deadline_timer
Next, instead of doing a blocking wait as in tutorial Timer.1,
we call the boost::asio::deadline_timer::async_wait() function to perform an
asynchronous wait. When calling this function we pass the <tt>print</tt>
callback handler that was defined above.
\skipline async_wait
Finally, we must call the boost::asio::io_service::run() member function
on the io_service object.
The asio library provides a guarantee that callback handlers will <b>only</b>
be called from threads that are currently calling boost::asio::io_service::run().
Therefore unless the boost::asio::io_service::run() function is called the callback for
the asynchronous wait completion will never be invoked.
The boost::asio::io_service::run() function will also continue to run while there is
still "work" to do. In this example, the work is the asynchronous wait on the
timer, so the call will not return until the timer has expired and the
callback has completed.
It is important to remember to give the io_service some work to do before
calling boost::asio::io_service::run(). For example, if we had omitted the above call
to boost::asio::deadline_timer::async_wait(), the io_service would not have had any
work to do, and consequently boost::asio::io_service::run() would have returned
immediately.
\skip run
\until }
See the \ref tuttimer2src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tuttimer1 \n
Next: \ref tuttimer3
*/
/**
\page tuttimer2src Source listing for Timer.2
\include timer2/timer.cpp
Return to \ref tuttimer2
*/
/**
\page tuttimer3 Timer.3 - Binding arguments to a handler
In this tutorial we will modify the program from tutorial Timer.2 so that the
timer fires once a second. This will show how to pass additional parameters to
your handler function.
\dontinclude timer3/timer.cpp
\skip #include
\until posix_time.hpp
To implement a repeating timer using asio you need to change
the timer's expiry time in your callback function, and to then start a new
asynchronous wait. Obviously this means that the callback function will need
to be able to access the timer object. To this end we add two new parameters
to the <tt>print</tt> function:
\li A pointer to a timer object.
\li A counter so that we can stop the program when the timer fires for the
sixth time.
\until {
As mentioned above, this tutorial program uses a counter to
stop running when the timer fires for the sixth time. However you will observe
that there is no explicit call to ask the io_service to stop. Recall that in
tutorial Timer.2 we learnt that the boost::asio::io_service::run() function completes
when there is no more "work" to do. By not starting a new asynchronous wait on
the timer when <tt>count</tt> reaches 5, the io_service will run out of work and
stop running.
\until ++
Next we move the expiry time for the timer along by one second
from the previous expiry time. By calculating the new expiry time relative to
the old, we can ensure that the timer does not drift away from the
whole-second mark due to any delays in processing the handler.
\until expires_at
Then we start a new asynchronous wait on the timer. As you can
see, the boost::bind() function is used to associate the extra parameters
with your callback handler. The boost::asio::deadline_timer::async_wait() function
expects a handler function (or function object) with the signature
<tt>void(const boost::system::error_code&)</tt>. Binding the additional parameters
converts your <tt>print</tt> function into a function object that matches the
signature correctly.
See the <a href="http://www.boost.org/libs/bind/bind.html">Boost.Bind
documentation</a> for more information on how to use boost::bind().
In this example, the boost::asio::placeholders::error argument to boost::bind() is a
named placeholder for the error object passed to the handler. When initiating
the asynchronous operation, and if using boost::bind(), you must specify only
the arguments that match the handler's parameter list. In tutorial Timer.4 you
will see that this placeholder may be elided if the parameter is not needed by
the callback handler.
\until boost::asio::io_service
A new <tt>count</tt> variable is added so that we can stop the
program when the timer fires for the sixth time.
\until boost::asio::deadline_timer
As in Step 4, when making the call to
boost::asio::deadline_timer::async_wait() from <tt>main</tt> we bind the additional
parameters needed for the <tt>print</tt> function.
\until run
Finally, just to prove that the <tt>count</tt> variable was
being used in the <tt>print</tt> handler function, we will print out its new
value.
\until }
See the \ref tuttimer3src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tuttimer2 \n
Next: \ref tuttimer4
*/
/**
\page tuttimer3src Source listing for Timer.3
\include timer3/timer.cpp
Return to \ref tuttimer3
*/
/**
\page tuttimer4 Timer.4 - Using a member function as a handler
In this tutorial we will see how to use a class member function as a callback
handler. The program should execute identically to the tutorial program from
tutorial Timer.3.
\dontinclude timer4/timer.cpp
\skip #include
\until posix_time.hpp
Instead of defining a free function <tt>print</tt> as the
callback handler, as we did in the earlier tutorial programs, we now define a
class called <tt>printer</tt>.
\until public
The constructor of this class will take a reference to the
io_service object and use it when initialising the <tt>timer_</tt> member. The
counter used to shut down the program is now also a member of the class.
\until {
The boost::bind() function works just as well with class
member functions as with free functions. Since all non-static class member
functions have an implicit <tt>this</tt> parameter, we need to bind
<tt>this</tt> to the function. As in tutorial Timer.3, boost::bind()
converts our callback handler (now a member function) into a function object
that can be invoked as though it has the signature <tt>void(const
boost::system::error_code&)</tt>.
You will note that the boost::asio::placeholders::error placeholder is not specified
here, as the <tt>print</tt> member function does not accept an error object as
a parameter.
\until }
In the class destructor we will print out the final value of
the counter.
\until }
The <tt>print</tt> member function is very similar to the
<tt>print</tt> function from tutorial Timer.3, except that it now operates on
the class data members instead of having the timer and counter passed in as
parameters.
\until };
The <tt>main</tt> function is much simpler than before, as it
now declares a local <tt>printer</tt> object before running the io_service as
normal.
\until }
See the \ref tuttimer4src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tuttimer3 \n
Next: \ref tuttimer5 \n
*/
/**
\page tuttimer4src Source listing for Timer.4
\include timer4/timer.cpp
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.
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
already know, the asio library provides a guarantee that callback handlers will
<b>only</b> be called from threads that are currently calling
boost::asio::io_service::run(). Consequently, calling boost::asio::io_service::run() from
only one thread ensures that callback handlers cannot run concurrently.
The single threaded approach is usually the best place to start when
developing applications using asio. The downside is the limitations it places
on programs, particularly servers, including:
<ul>
<li>Poor responsiveness when handlers can take a long time to complete.</li>
<li>An inability to scale on multiprocessor systems.</li>
</ul>
If you find yourself running into these limitations, an alternative approach
is to have a pool of threads calling boost::asio::io_service::run(). However, as this
allows handlers to execute concurrently, we need a method of synchronisation
when handlers might be accessing a shared, thread-unsafe resource.
\dontinclude timer5/timer.cpp
\skip #include
\until posix_time.hpp
We start by defining a class called <tt>printer</tt>, similar
to the class in the previous tutorial. This class will extend the previous
tutorial by running two timers in parallel.
\until public
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.
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.
\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.
\until }
\until }
In a multithreaded program, the handlers for asynchronous
operations should be synchronised if they access shared resources. In this
tutorial, the shared resources used by the handlers (<tt>print1</tt> and
<tt>print2</tt>) are <tt>std::cout</tt> and the <tt>count_</tt> data member.
\until };
The <tt>main</tt> function now causes boost::asio::io_service::run() to
be called from two threads: the main thread and one additional thread. This is
accomplished using an boost::thread object.
Just as it would with a call from a single thread, concurrent calls to
boost::asio::io_service::run() will continue to execute while there is "work" left to
do. The background thread will not exit until all asynchronous operations have
completed.
\until }
See the \ref tuttimer5src "full source listing" \n
Return to the \ref index "tutorial index" \n
Previous: \ref tuttimer4 \n
*/
/**
\page tuttimer5src Source listing for Timer.5
\include timer5/timer.cpp
Return to \ref tuttimer5
*/
Reference in New Issue View Git Blame Copy Permalink