Re: [Boost-users] ASIO io_service behaviour

Subject: Re: [Boost-users] ASIO io_service behaviour
From: Igor R (boost.lists_at_[hidden])
Date: 2008-11-02 09:45:09

Hi,

> The reason I was expecting them to be called in that order was because of the timings on each of the deadline_timers. I was expecting a 6 second wait for bleh to be printed which is what happened, then a 1 second wait for print1 to be called, then another second wait for print2 to be called and so on.

The timings in your case are irrelevant. Lets see what happens:

{
       boost::asio::io_service io;
       boost::asio::deadline_timer t(io, boost::posix_time::seconds(6));
       boost::asio::io_service io2;
       boost::asio::deadline_timer t1(io2, boost::posix_time::seconds(1));
       boost::asio::deadline_timer t2(io2, boost::posix_time::seconds(2));
       boost::asio::deadline_timer t3(io2, boost::posix_time::seconds(3));
       boost::asio::deadline_timer t4(io2, boost::posix_time::seconds(4));
       t.async_wait(printHello);
       t1.async_wait(print1);
       t2.async_wait(print2);
       t3.async_wait(print3);
       t4.async_wait(print4);
       // point A
       io.run(); // point B
       std::cout << "bleh\n";
       io2.run(); // point C
}

At the point A all the timers are "cocked".
The execution of your main thread cannot proceed beyond the point B
until all the work of the "io" is done. This happens when the timer
"t" is expired, i.e. in 6 seconds. When you come to the point C, *all*
of the timers that are serviced by "io2" are already expired, but
their handlers didn't have a chance to execute because the io2 is not
running yet. Now, when you run the "io2", all the handlers will
execute - in some implementation-defined order.