Boost logo

Boost :

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 ( 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
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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at