Hi Eddie, Please find my comments below.
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.
I agree in spirit, but the details make a library of this kind unlikely to work. For example, (on Windows) the techniques used for async file I/O are completely different than async network I/O. Even pipe I/O is just slightly different that file I/O. What I have found is that all one can hope for is a pattern with which async operations should be designed. The implementation details may be shared in some cases, but not enough to make those much of a reusable library. For example, I created a socket select/poll engine at work, and it was highly portable for the purposes of sockets. It could be applied to file descriptors in general on Unix, but as that was only helpful for those platforms, I didn't give it much polish. Async file I/O has a completely different implementation, as did async pipe I/O.
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.
See above. The means by which asynchronicity is gained differs by API and OS, making a general, reusable async I/O library impracticle.
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.
Some non-portable portions can be made reusable, but still specific to a certain part of the overall async I/O problem. To me, this means that the async I/O facility is of use to very few people and should be concidered an implementation detail.
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.
I agree; a general async library can go a long way to making async programming real. The I/O problem is a thing to solve on top of that.
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.
That's the hope :) Best, Don __________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest