From: Ariel Badichi (abadichi_at_[hidden])
Date: 2005-08-19 17:20:16
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.
> - 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
> * 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk