Hi folks, I am using the latest version of Boost ASIO on a Suse11 box. I recently upgraded from an older version of Boost, and life since then has been unusually harsh. **** I have a piece of ASIO code that worked just fine earlier but doesn't do so now. Here's the offending snippet, rather simple looking: **** boost::asio::streambuf response; ... // code for deadline timer tcp::socket socket(io_service); socket.async_connect(*iterator, &conn_handler); io_service.reset(); io_service.run_one(); async_write(socket, buffer(command.c_str()), &write_handler); io_service.reset(); io_service.run_one(); async_read_until(socket, response, '\n', &read_handler); io_service.reset(); io_service.run_one(); Everything works fine till async_write. During async_read_until I can see that the response buffer does have some data by the time it returns. However, when io_service.run_one() happens the read_handler is NOT ALWAYS called which is very surprising. The function calling the read_handler (internal to ASIO) also does a commit to the streambuf so streambuf.size() becomes non-zero, i.e. ready for consumption by something like istream. All of that is missing now. Debugging this in some detail, I see that run_one is in fact responsible for calling read_handler. That is NOT happening and in epoll_reactor I am not seeing any real activity. Something there is activity and the behavior is as expected but 9/10 times completion handler won’t be called. The io_service object runs in a specific thread (I have a bunch of threads in my app) and no other thread accesses it. The Linux kernel running previous version has not been changed when I upgraded the Boost libraries. Instead of epoll, if I use select everything looks good. Any thoughts? Arpan