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/htm...) 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
[...]