Boris wrote:
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?
Similarly, but using the facilities of modern C++. There is no need to exactly emulate .NET's design when C++ provides a possibly richer way of doing things.
There should be an asynchronicity library based on threads and callbacks (and maybe some other features).
Agreed. A separate asynchronous library which has nothing to do with I/O per se but rather defines a model for doing callbacks in threads which can be invoked asynchronously.
Then we have a network library supporting different models of I/O including asynchronous I/O.
The reason I posited a separate library for purely asynchronous I/O, rather than folding that into the network library, is that there are models in which an asynchronous I/O library may have nothing to do with network access. For instance it is possible in some operating systems to read/write files asynchronously. Should this come under the aegis of a network library ? I do not think so since the file I/O will normally occur locally. On the other hand, remote access to files may be thought of as network functionality and it may be possible to do file I/O remotely asynchronously. So my point was simply that an asynchronous I/O model may be something that can be used by more than just a network library and may be considered separately.
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.
Agreed.
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.
That is the idea. If the pattern is flexible enough, an asynchronous I/O library could be useful outside of what is thought of as networking operations. It all depends on what is considered "network programming" and what is not. If I send data through a USB port to read/write from/to a hardare device, is that "network programming" ? Probably not, but a good asynchronous I/O model might be built that can be used in that situation also. C++ currently has a standard I/O library. Many people may not like it because of its complexity but it was designed to be broadly applied and to be flexible for many forms of I/O. Unfortunately it is purely synchronous, mainly because the idea of asynchronicity was considered outside the sope of the standard C++ libraries and outside the scope of the language itself, not to speak also of the idea of threading. In the same way a general purpose asynchronous I/O library could serve the same purpose as the standard C++ "synchronous" I/O library.
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?
Yes, see argument above. The main reason for my argument is reuse by other libraries doing asynchronous I/O but which may not be network related. If the network library is going to support asynchronous operations, which is only natural because of the time it takes for things to happen over networks, other libraries not defined as "network" but still wanting to offer asynchronous I/O operations could use a general purpose asynchronous I/O library to achieve their ends also. Of course all this is theoretical design. It may be that the ideas of a separate asynchronous library, asynchronous I/O library, and network library are unrealistic and one can not separate these things as cleanly as I would believe, but I still think the idea of having these libraries for re-use is the right one. Even just a separate asynchronous library could be used when not doing I/O but just wanting to provide asynchronous "background" operations for processes which have to be responsive to end-user input. Of course separate asynchronous libraries and asynchronous I/O libraries exist in C++ but their models appear to me to be essentially C procedural programming models. Modern C++ should be able to come up with things that are more robust and take advantage of possibly both OOP programming and generic programming knowledge. Eddie