Hi all, I have got some code to test the behavior of io_service. The relevant code is as follows: void ioservice_lifotest() { 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); io.run(); std::cout << "bleh\n"; io2.run(); std::cout << "done\n"; } printHello(), print1(), print2(), print3() and print4() are simple functions that print different messages to the console. I was expecting printHello to be called first, then print1, then print2, then print3 and print4, because that is the order the events were added to the io_service service. However these functions were called in reverse order. It is as though the underlying queue mechanism is actually a stack. I expect I have missed some of, or misunderstood the documentation, but a few hints as to what is happening will be appreciated. -- Regards, Phil E: philip.gaskell@momote.com | M: +44(0)7891 199 959 | W: www.momote.com EMAIL DISCLAIMER The contents of this electronic mail message and any attachments (collectively " this message") are confidential, possibly privileged and intended only for its addressee ("the addressee"). If received in error, please delete immediately without disclosing its contents to anyone. Neither the sender nor its management or employees will in any way be responsible for any advice, opinion, conclusion or other information contained in this message or arising from its disclosure. Registered office: 8 The Parks, Haydock, Newton-Le-Willows, Merseyside. WA12 0JQ Registered in England No. 4410772.
I was expecting printHello to be called first, then print1, then print2, then print3 and print4, because that is the order the events were added to the io_service service.
I expect I have missed some of, or misunderstood the documentation, but a few hints as to what is happening will be appreciated.
I do not see anything in the documentation that could make you think so -- could you please quote the documentation excerpt you refer to? I think the order of handlers invocation in your case is implementation-defined and it's not a good idea to rely on it.
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. What actually happens after bleh is printed is a 4 second pause then all the functions are called in reverse order immediately. Regards, Phil E: philip.gaskell@momote.com | M: +44(0)7891 199 959 | W: www.momote.com EMAIL DISCLAIMER The contents of this electronic mail message and any attachments (collectively " this message") are confidential, possibly privileged and intended only for its addressee ("the addressee"). If received in error, please delete immediately without disclosing its contents to anyone. Neither the sender nor its management or employees will in any way be responsible for any advice, opinion, conclusion or other information contained in this message or arising from its disclosure. Registered office: 8 The Parks, Haydock, Newton-Le-Willows, Merseyside. WA12 0JQ Registered in England No. 4410772. Igor R wrote:
I was expecting printHello to be called first, then print1, then print2, then print3 and print4, because that is the order the events were added to the io_service service.
I expect I have missed some of, or misunderstood the documentation, but a few hints as to what is happening will be appreciated.
I do not see anything in the documentation that could make you think so -- could you please quote the documentation excerpt you refer to? I think the order of handlers invocation in your case is implementation-defined and it's not a good idea to rely on it. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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.
participants (2)
-
Igor R -
Philip Gaskell