By going through the doc. i understand that async completion handlers will be called whenever io_service::run() reads posted events from the queue for which the corresponding handlers were registered by us. Now if i have a registered handler for some event (say async_wait() of deadline_timer) which does something time consuming, then event loop (io_service::run()) does not get a chance to read the event queue until the handler returns thus preventing calls to other handlers for which events are queued. I've tested this behaviour with timers and it works as expected. However i could not understand the behaviour of async_read_from() of udp::socket. void A::read() { udpSoc.async_receive_from( boost::asio::buffer(m_cRxData, 1024), m_endpoint, boost::bind(&A::readHandler, this, _1, _2) ); } ////////////////////////////// <1> /////////////////////////// void A::readHandler(......) { std::string szDatagram(m_cRxData, bytesReceived); std::cerr << "Rxd Datagram: " << szDatagram << std::endl; read(); //............ } ////////////////////////////// <2> /////////////////////////// void A::readHandler(......) { read(); std::string szDatagram(m_cRxData, bytesReceived); std::cerr << "Rxd Datagram: " << szDatagram << std::endl; //............ } in above when 2 datagrams arrive simultaneously, readHandler <1> works fine but <2> does not. In <1> std::cerr write 1st and 2nd Datagrams distinctly, but in <2> data gets corrupted and std::cerr writes a string that would be formed if the 1st datagram in it were overwritten by the 2nd datagram (ie., if 1st one was 12345 and 2nd one xyz then <2> above prints "xyz45".) This means that clearly m_cRxData (which is a private member) is getting overwritten. Why does this happen? async_read_from should return immediately without reading into m_cRxData, readHandler(..) should continue and complete, and control should reach event loop, and then finally async read should be done calling the completion handler. Is this explanation wrong? -- View this message in context: http://boost.2283326.n4.nabble.com/Behaviour-of-asio-tp4642911.html Sent from the Boost - Users mailing list archive at Nabble.com.