I'm under the impression that queueing several async reads will allow the OS to fill one buffer while the read handler for a previous read is still executing. This comes partly from reading: http://www.jetbyte.com/portfolio-showarticle.asp?articleId=44&catId=1&subcatId=2 Although I can't find any mention of this practice in the asio docs or examples, it seems to "mostly work". And it makes logical sense. My program is: - Single-threaded - Not using "composed" reads (ie boost::asio::async_read) On Linux this technique works fine for multiple pending reads. On Windows, it sometimes leads to handlers being called in the wrong order. My sample program (attached) can be called in 2 ways: a) to write a known data stream to a socket b) to compare the same stream of data to bytes being read from a socket via multiple async_receive()s. So in one terminal, receive data using 8 concurrent async_receives: async_recv.exe receive 8 and in the other: async_recv.exe send On Windows (XP Pro 64, boost 1.39), the first program exits within a few seconds saying "streams differ". I haven't been able to reproduce the failure on XP Pro 32, Server 2003 or Linux, although this may just be timing dependent. Am I doing something wrong or unreasonable? Thanks! Pete