Iain Hanson wrote:

On Fri, 2005-04-01 at 13:53 +0300, Boris wrote:

While asynchronicity in .NET is basically based on threads it is not true for asynchronous I/O. If you built asynchronous I/O on top of an asynchronicity library with callbacks in threads you will end up with 1000 threads blocked in read() if you have 1000 sockets.

No. This would be a configuration or implementation detail. The only requirement is that you have at least 1 thread dispatching async requests and queueing work to be dispatched. LibC AIO has an init function where the user can supply a hint regarding size of thread pool to use. I think the contract for a C++ lib should be stronger and allow the user to specify/control the size of the thread pool as well as the type of the ACT ( not just callback, but signal and polling ).

I don't think our opinions are very different. You agree that library users should have some control about the implementation for a better performance. There is really a trade-off between design and performance. As we have seen in another thread today's operating systems don't support asynchronous I/O very well. In Linux asynchronous I/O would be probably best implemented using epoll() as multiplexing is the traditional *unix way. A C++ network library which can't support efficient I/O because of its design won't be of much use. It could be perfectly designed but it couldn't be implemented using best available I/O APIs on different operating systems. Boris