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.