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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk