[boost] Re: Re: Asynchronicity (long)

From: Boris (boris_at_[hidden])
Date: 2005-04-01 10:02:39

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