It seems that network sockets are the most common use case for nonblocking I/O multiplexing (i.e. the reactor pattern). If a library restricts itself to those alone, an efficient portable implementation may be possible. Note, for example, that AFAIK, polling multiple file descriptors for reading or writing (this is not the same as waiting for asynchronous completion) is not possible under the Windows API, while under POSIX, Linux, and BSD, AFAIK, it is not possible to wait on a set of mutexes or condition variables while also polling a set of file descriptors. These two constraints effectively rule out creating a boost i/o library that can handle polling anything but sockets. Clearly, using multiple threads to attempt to emulate this type of polling is not a viable solution, because it would likely be highly inefficient. On the other hand, I believe it would be possible to create a portable library which utilized either WSAAsyncSelect or select on Windows platforms, kqueue on BSD platforms, epoll on Linux kernels that support it, and poll on other POSIX platforms. (On Solaris, I believe it would be possible to utilize /dev/poll.) As far as asynchronous read/write (on sockets) handling, I do not believe it is possible to unify waiting for asynchronous completion with the type of polling described above, at least on POSIX platforms. It would be possible to create a portable library for waiting (only) for asynchronous completion of a read or write. One issue with the POSIX asynchronous i/o interface is that it does not, AFAIK, support reading or writing asynchronous out-of-band data on TCP sockets. I suppose though that since out-of-band data is not used all that often, this is less of an issue; still, it is a reason for people to use polling rather than asynchronous read/write, particularly since in a network server, it would be necessary to have at least one thread waiting to accept new clients. -- Jeremy Maitin-Shepard