Boost logo

Boost :

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
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


> [...]

Boost list run by bdawes at, gregod at, cpdaniel at, john at