Edward Diener wrote:
[...]
But how does the network library provide asynchronous I/O operations to the library user?
That is up to the network library designer/implementer but I see no reason why the network library can not provide both synchronous and asynchronous functionality in a number of areas. This is very similar to the way that sockets, as an example, works in .NET, where one can call certain functionality either synchronously, waiting for the call to finish, or asynchronously, returning to do other things while the call will finish when a delegate on another thread is invoked.
Maybe I didn't explain myself very good because I also like how .NET supports asynchronous operations. :) If I take the socket class in .NET as an example: You could call Socket.Connect() asynchronously like any other function using a delegate. However the socket class supports asynchronous I/O explicitly providing a BeginConnect() and EndConnect() method which is more efficiently implemented. However there is an asynchronous design pattern in .NET so whoever designed BeginConnect() and EndConnect() had to follow some rules. As far as I understand you agree that we should do in C++ similarly? There should be an asynchronicity library based on threads and callbacks (and maybe some other features). Then we have a network library supporting different models of I/O including asynchronous I/O. The asynchronous support will be explicitly provided by the network library. The library user doesn't need to use the asynchronicity library himself to do asynchronous I/O as there will be explicit support just like in .NET. How this explicit support of asynchronous I/O is implemented doesn't matter. If we agree upon this we need an asynchronous design pattern in C++, too. Asynchronous I/O support in a network library must be then designed according to this pattern. And of course any other library which will support asynchronous operations explicitly have to follow this design pattern, too.
If you tell me that's up to the network library asynchronous I/O provided by the network library will be used differently than what eg. an asynchronicity library might provide.
The challenge of an asynchronous I/O library is to provide a general enough interface to allow other more specific libraries to use it for their own specific asynchronous I/O purposes, else there is little purpose in creating it.
Until now I was thinking about an asynchronicity library and a network library. You think about putting another library in between - an asynchronous I/O library? Boris
[...]