Firstly, I think the library should be accepted into Boost. I can't see any particular blocking issues that would prevent it being acceptable, and it is high time that some network library is available in boost, to serve as a basis for more abstract facilities. - What is your evaluation of the design? Fine, based on well understood models. - What is your evaluation of the implementation? I haven't looked. - What is your evaluation of the documentation? The documentation is quite good. I would prefer a slightly more discursive style, but the reference information is all there, and the tutorials are a good introduction. I think the examples each need a description, explaining what they exemplify. Also, many of the examples contain some code repetition, where a handler repeats task initiation code also found outside the handler; I think these should be refactored. - What is your evaluation of the potential usefulness of the library? Enormous. - Did you try to use the library? With what compiler? Did you have any problems? No. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Based on reading the documentation only. - Are you knowledgeable about the problem domain? Sockets programming, yes; asynch frameworks, no. I have a number of questions regarding the current proposal (I don't think any of these require changes before acceptance, but I am curious.) Please excuse the lack of structure to these questions :) I don't really follow the intent of the locking dispatcher. It appear to me that it simply achieves the same effect as adding a scoped lock to each dispatched method (each using the same mutex). This gives a small reduction in code, but doesn't immediately strike me as giving the code greater clarity. Also, the shared mutex that would otherwise be used in each method would be available for protecting other related code, while the locking_dispatcher hides the mutex, so that all protected code must be invoked via the demultiplexer. Perhaps a better example than that in the tutorial would make the benefit of the dispatcher clearer? The locking_dispatcher's 'wrap' method seems to be its primary purpose. Since the terminology is a little unnatural, perhaps it could be operator() ? I would like to see a user-supplied handler option for handling genuine errors, not per-call but at a higher level (maybe per-demuxer?) Typically, the response to an error is to close the socket, once open; it would be handy to supply a callback which received enough context to close down a socket, and in all other code to ignore error-handling completely. I do not think EOF should constitute an error, and I would expect that try-again and would-block errors could be safely ignored by the user. Perhaps EOF should be a testable state of the socket, rather than a potential error resulting from 'receive'. Can the proactor be made to work with multiple event sources, with the current interface? For example, wrapping simultaneous network IO and aio-based file IO on POSIX? I wonder how the demuxer would be incoporated into a GUI event-loop-based program, particularly in toolkits which mandate that GUI updates can occur from a single thread only? Perhaps the 'run' member function could be called in a non-blocking fashion? Or perhaps the demuxer could queue ready handler callbacks for later execution, rather than invoking them directly? Then the GUI thread could execute all pending handler functions on idle. I believe there should be an automatically managed buffer-list class, to provide simple heap-based, garbage-collected buffer management, excluding the possibility of buffer overruns and memory leaks. Perhaps the one in the Giallo library could be used without significant modification, and supported by the asio buffer primitives. Also, this abstraction should be used in tutorials; although it is useful and practical to support automatically allocated buffer storage, it shouldn't be needlessly encouraged. I also would like to request some commentary (in the library documentation) on future developments that are out of scope for the current proposal. Given the late juncture at which we're looking at bringing network programming into boost, I think it's important to consider desirable extensions, and how the current proposal will support them. Much of this will be discussed in the review, of course. One thing I would like to see (even in Asio itself) is a simplest-possible layer over the bare sockets layer, which took care of resource management and the intricacies of sockets programming. Ideally, this would leave an interface comparable to asynch IO programming in python and the like, suitable for the smallest networking tasks. Other, more complicated layers, such as socketstreams and compile-time filter-chaining as in Giallo, could be provided as libraries built on Asio. Matt