Christopher Kohlhoff wrote: [snipped parts irrelevant to my reply]
As discussed in the "surveying async network io libraries" thread, I'd like to turn asio (asio.sourceforge.net) into a proposal for a boost networking library. As promised, here is a list of areas where asio could use some refinement.
Great!
- Any other things that should be on the list.
I experimented with the library for a few days now. Maybe I'm misusing it, but it seemed nice to have demuxer::run() thread(s) running before any (meaningful) asio operation is performed. My solution was a demuxer::run() thread pool management class (using boost::thread_group to manage the threads themselves). The class has a timer that keeps queueing itself in its handler, unless the class's client requested it to stop. The stop operation also joins the thread(s). If it's a legitimate use, a helper class to do that can be useful. If not, why?
* More examples.
* Documentation on design and rationale.
These are the two most important improvements.
* The use of the word "Stream" can be confusing because its existing association in C++ with iostreams. Can anyone suggest an alternative?
The use of "stream" in this context seems natural enough for me. I suspect most people writing networking code will agree.
* Should stream_socket and dgram_socket be merged into a single socket class? There other types of sockets (e.g. sequenced packet) that would require additional classes if the current approach is retained. This would not be required if the BSD socket APIs were covered by a single class. Alternatively, should additional classes be added for the other socket types?
My instinct tells me that they shouldn't be merged: they are very different concepts, and I wouldn't like this specific abstraction eliminated in asio.