Johnathan,
character c; while ((c = boost::io::get(src)).good() && !isalpha(c)) ;
Basically, I do not see any scenario where you would want to write a buffer to a modern operating system one character at a time, more or less do so asynchronously. The above quoted code needs to be buffered to be useful and there is no reason to write to a user-mode buffer asynchronously. So my recommendation is that this particular type of filter should remain oblivious to asynchronous IO. It would be helpful to think of asynchronous IO in terms of two basic paradigms: 1. user-mode synchronous/kernel mode asynchronous IO. 2. user-mode asynchronous/kernel mode asynchronous IO. The first paradigm does not require any particular modification of your library. As I already mentioned, I have overlapped IO working with your library in its current form. The IOStreams library has no reason to know or care that I am blocking in user rather than kernel mode. The second paradigm (for example, using IO completion ports) is very difficult to fit within the Standard Library stream and filebuf concepts. The logic is quite different. To begin with read and write will need at least one additional parameter that encapsulates OS specific thread local stream state, including stream position and asynchronous io result. Second, you will need some way to retrieve extended error information on a stream that differentiates between failure that indicates the io operation is pending and failure that indicates no further processing is possible. Sockets, DCOM and CORBA all have conceptions of extended error info on procedures. Windows has GetLastError(). Exceptions might be used but they suck up too many cpu cycles for an error condition that is expected on virtually every asynchronous io operation. Perhaps you might just introduce an io_pending_bit into your stream state. But I would leave the return value alone. Finally, you need some way to relinquish the read or write buffer, and its lifetime, to the asynchronous completion port. My current problem is that I have just discovered that your line_wrapping_output_filter is writing to my overlapped_filebuf one character at a time. I purposely did not implement buffer in it because this is not thread-safe and must occur at a higher level. I need a buffering filter or wrapper. Hope this helps. Regards, George.