Boost logo

Boost :

From: Matthew Vogt (mattvogt_at_[hidden])
Date: 2005-12-13 05:34:45

Firstly, I think the library should be accepted into Boost.
I can't see any particular blocking issues that would prevent it being
acceptable, and it is high time that some network library is available in boost,
to serve as a basis for more abstract facilities.

- What is your evaluation of the design?
Fine, based on well understood models.

- What is your evaluation of the implementation?
I haven't looked.

- What is your evaluation of the documentation?
The documentation is quite good. I would prefer a slightly more discursive
style, but the reference information is all there, and the tutorials are a good
introduction. I think the examples each need a description, explaining what
they exemplify. Also, many of the examples contain some code repetition, where
a handler repeats task initiation code also found outside the handler; I think
these should be refactored.

- What is your evaluation of the potential usefulness of the library?

- Did you try to use the library? With what compiler? Did you have any

- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
Based on reading the documentation only.

- Are you knowledgeable about the problem domain?
Sockets programming, yes; asynch frameworks, no.

I have a number of questions regarding the current proposal (I don't
think any of these require changes before acceptance, but I am curious.) Please
excuse the lack of structure to these questions :)

I don't really follow the intent of the locking dispatcher. It appear to me
that it simply achieves the same effect as adding a scoped lock to each
dispatched method (each using the same mutex). This gives a small reduction in
code, but doesn't immediately strike me as giving the code greater clarity.
Also, the shared mutex that would otherwise be used in each method would be
available for protecting other related code, while the locking_dispatcher hides
the mutex, so that all protected code must be invoked via the demultiplexer.
Perhaps a better example than that in the tutorial would make the benefit of the
dispatcher clearer?

The locking_dispatcher's 'wrap' method seems to be its primary purpose. Since
the terminology is a little unnatural, perhaps it could be operator() ?

I would like to see a user-supplied handler option for handling genuine errors,
not per-call but at a higher level (maybe per-demuxer?) Typically, the response
to an error is to close the socket, once open; it would be handy to supply a
callback which received enough context to close down a socket, and in all other
code to ignore error-handling completely.
I do not think EOF should constitute an error, and I would expect that try-again
and would-block errors could be safely ignored by the user. Perhaps EOF should
be a testable state of the socket, rather than a potential error resulting from

Can the proactor be made to work with multiple event sources, with the current
interface? For example, wrapping simultaneous network IO and aio-based file IO

I wonder how the demuxer would be incoporated into a GUI event-loop-based
program, particularly in toolkits which mandate that GUI updates can occur from
a single thread only? Perhaps the 'run' member function could be called in a
non-blocking fashion? Or perhaps the demuxer could queue ready handler
callbacks for later execution, rather than invoking them directly? Then the GUI
thread could execute all pending handler functions on idle.

I believe there should be an automatically managed buffer-list class, to provide
simple heap-based, garbage-collected buffer management, excluding the
possibility of buffer overruns and memory leaks. Perhaps the one in the Giallo
library could be used without significant modification, and supported by the
asio buffer primitives. Also, this abstraction should be used in tutorials;
although it is useful and practical to support automatically allocated buffer
storage, it shouldn't be needlessly encouraged.

I also would like to request some commentary (in the library documentation) on
future developments that are out of scope for the current proposal. Given the
late juncture at which we're looking at bringing network programming into boost,
I think it's important to consider desirable extensions, and how the current
proposal will support them. Much of this will be discussed in the review, of

One thing I would like to see (even in Asio itself) is a simplest-possible layer
over the bare sockets layer, which took care of resource management and the
intricacies of sockets programming. Ideally, this would leave an interface
comparable to asynch IO programming in python and the like, suitable for the
smallest networking tasks. Other, more complicated layers, such as
socketstreams and compile-time filter-chaining as in Giallo, could be provided
as libraries built on Asio.


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