What is the execution stream of Asio? - asynchronous

Question

I have a test program as below:
io_service io;
deadline_timer t1(io);
deadline_timer t2(io);
t1.expires_from_now(boost::posix_time::seconds(10));
t1.async_wait([](const boost::system::error_code &error) {
if (error == boost::asio::error::operation_aborted) {
cout << "timer1 canceled" << endl;
} else {
cout << "timer1 expired" << endl;
}
});
t2.expires_from_now(boost::posix_time::seconds(2));
t2.async_wait([&t1](const boost::system::error_code &error) {
if (error == boost::asio::error::operation_aborted) {
cout << "timer2 canceled" << endl;
} else {
t1.cancel();
for (int i = 0; i < 5000000; i++) {
cout << i << endl;
}
# usleep(1000000);
std::this_thread::sleep_for(std::chrono::milliseconds(1000));
cout << "timer2 expired" << endl;
}
});
io.run();
I was wondering when timer2 expires and cancels timer1, which one of "timer1 canceled" and "timer2 expired" will print as first?
The result is "timer2 expired". It makes sense as the single thread program will execution until some "block" happens.
But after inserting the line "sleep_for(1000ms)" (which should block the execution, trans the process to "Sleep"), the line "timer2 expired" still print before the line "timer1 canceled".
In my imagination, the boost:asio is something written around the "epoll" which can deal between "events" like incoming messages from network (the timer2 expires) and "blocks" like writing to disk (the sleep) in a single thread. But why didn't the line "timer1 canceled" reveal after "sleep_for"?
Question2: Assuming a program handling network request and Chrono jobs, in one thread.
void fun1(){
timer1.expire_from_now(3s);
timer1.async_wait([](const & error){
cout<<"timer1 expired";
heavy_job();
});
}
The fun1 expired, and executed cout<<"timer1 expired", but not executed. heavy_job yet. At this time, a request from network triggered fun2:
int wait_funcs= timer1.expire_from_now(3s);
if (wait_funcs == 0 ){
job2();
}else{
job3();
}
which of the following situation will happen?
heavy_job done -> job2:
which means func1 will not be interrupted by fun2, fun2 will run after fun1 completes(or blocks?)
job2 done -> heavy_job:
which means the wait_funcs check detected the unsafe behavior
Sorry about my demonstration, I am new to boost:asio and confused.

Answer 1

You can think of io_service as a producer-consumer queue: whenever an asyncronous operation gets completed (or aborted), its completion handler is pushed into the queue; while, on the other hand, io_service::run() fetches these handlers from the queue and invokes them.
Also note that as long as your program is single threaded (and does not use co-routines), all the completion handlers are always executed sequentially, one by one.
So, in you first example t2 timer expires first, and the completion handler gets invoked. The handler of t1 will not be fetched from the queue until the previous one completes - it doesn't matter how long it will take.
The same applies to your second example: the completion handler of timer1 is being run in the context of io_service::run, so the latter cannot fetch any subsequent handler until the previous one is done. So, if heavy_job() takes too long to complete, all other handlers will be stuck in the queue.