[boost] Re: Asynchronicity (long)

From: Boris (boris_at_[hidden])
Date: 2005-04-01 05:53:02

Edward Diener wrote:
> Please consider the general design of having asynchronous I/O handled
> by callbacks in threads. The callbacks can be easily designated by
> Boost Function functions and there is already a Boost Thread library
> for creating and manipulating threads. I have already worked in such
> an environment, albeit with .NET and not the Boost libraries, but I
> know this general model works well and is very flexible. How
> asynchronous I/O is specifically implemented in this model is up to
> the programmer(s) who create it, but I do not see a reason to invent
> a model which has already been proven to work
> well and which can be supported by other libraries which Boost already
> incorporates.

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. This doesn't happen in 
.NET and I don't think anyone want this to happen in a C++ network library. 
As an asynchronicity library doesn't know if a blocking function does I/O it 
will always call this function in a thread. The network library however 
knows better and can provide a much more efficient implementation of 
asynchronous I/O than an asynchronicity library can do. However in order not 
to confuse the application programmer asynchronous operations should look 
the same: rules for naming functions that do asynchronous operations, 
basically similar signatures of these functions etc. .NET has these rules 
(see 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconasynchronousdesignpatternoverview.asp) 
and it apparently works well. From this webpage: "The called object can 
choose to explicitly support asynchronous behavior, either because it can 
implement it more efficiently than a general architecture ..." In my opinion 
a socket is such an object which should explicitly support asynchronous 
behavior.

Boris

> [...]