Since you propose a Boost library, it would be a valuable exercise to consider how best to integrate your framework with Asio -- especially considering that something very like Asio is well on its way to becoming part of the C++ Standard.
Not sure if that was intended for me or the OP, but in AFIO's case we cannot be in any way compatible with ASIO's io_service. On POSIX async file and socket i/o use completely incompatible systems, and on Windows the 99% latencies with file i/o on IOCP are an order of magnitude worse than the alertable i/o mechanism used by AFIO. Besides, according to empirical testing, most users will not want to use async file i/o with anything but non-cached i/o i.e. 4Kb multiples to 4Kb aligned offsets. Async i/o with cached i/o is never better, and usually much worse, than synchronous i/o on SSD or better storage. AFIO v2 is designed accordingly, there isn't much async actually in there compared to v1. Hardware and OSs have very significantly changed. A whole new generation of storage (DAX) lands next year, it appears to the CPU as if it were RAM, so it's basically permanently mapped into memory and taking advantage of that 64 bit address space. AFIO performs excellently on such storage, nanosecond scale i/o latencies. But it completely upends how you design i/o, for example iostreams really sucks on DAX storage, it's unbelievably inefficient. You simply cannot max out a DAX device if you're using iostreams, not even close. I may float AFIO for standardisation next year. C++ will need to keep up with hardware improvements in order to stay relevant. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/