Here's my review of asio. First, i think asio should be accepted into boost. I built and ran several examples, on VC8.0. They built noisily (an issue with the vc8.0 safe c++ library rather than asio) but worked fine. I also coded up some tests of my own, and found the facilities were generally easy to follow and complete. (A minor niggle with the API was the order of parameters in async operations - i.e. with flags preceding the Handler parameter, not allowing a default of 0 to be used for flags.) I also couldnt see whether QOS was settable, a feature in use in media streaming libraries at my workplace. The ability to use boost::bind to specify and compose handlers is terrific and offers great flexibility in use of the library. Tools for some standard handler compositions (such as splittig error handling paths from mainline paths) would be welcome. On the same lines, Chris's abstract_dispatcher class (not currently part of asio) would be useful as part of the base lib. Beyond that much of my review activity has focussed on evaluating the threading system. Given that the threading system primarily exists to dispatch i/o events back into application code i can't fault it from this perspective. It provides an easily understood scheme for providing thread(s) to the asio in which callbacks can occur. Comments indicate that the mechanism used to trigger the callback is very efficient. Perhaps this is at the cost of tight coupling between the demuxer threading facilities and other parts of the library, favouring high throughput apps rather than customisability. The locking_dispatcher in combination with the demuxer offers some great ways isolate areas of code, or groups of objects from eachother without having to do a lot of explicit thread protection. I like it a lot. The richness of behavour offered by the demuxer/locking_dispatcher/ boost::function/boost::bind combination really raises asio to the level of an application-wide framework for asynchronous programming, not just with i/o entities like sockets and files, but with any technology that a programmer might need to integrate into an app. Particularly what i mean here is that its desirable to use the same demuxer-controlled threads to do callbacks when events arise from those technologies (e.g. legacy libraries that insist on calling back in their own privately created thread). This would make available the same pseudo-single threaded programming model throughout the app. Another factor is that for many apps (win32 GUI being my favorite example) the programmer doesnt want callbacks on a thread calling demuxer::run(), but on some other special purpose thread that cannot be locked up in the demuxer. This can be achieved in the win32 gui case using something comparable to a locking_dispatcher that reflects the event into that thread by a windows message. That however breaks the guarantees of the dispatcher concept ('callbacks will occur in a thread in demuxer::run()') It may be an acceptable compromise, but perhaps the concept is too specific and tied to the implementation. Anyway, the upshot of all this is i think that longer term the event dispatcher system in asio should be generalised into another library upon which asio should depend. This library could be the basis of other asynch programming efforts unrelated to i/o. It could offer more general guarantees about what thread executes a callback, and allow wider customisation than asio. Thanks Chris for the excellent library, and responding to my somewhat noisy posting. Cheers Simon