Re: [boost] asio formal review begins

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-18 02:36:28

Here's my review of asio.

First, i think asio should be accepted into boost.

I built and ran several examples, on VC8.0. They
built noisily (an issue with the vc8.0 safe c++ library rather
than asio) but worked fine. 

I also coded up some tests of my own, and found the facilities
were generally easy to follow and complete.
(A minor niggle with the API was the order of parameters in 
async operations - i.e. with flags preceding the Handler
parameter, not allowing a default of 0 to be used for flags.)

I also couldnt see whether QOS was settable, a feature 
in use in media streaming libraries at my workplace.

The ability to use boost::bind to specify and compose handlers
is terrific and offers great flexibility in use of the library. 
Tools for some standard handler compositions (such as
splittig error handling paths from mainline paths) would
be welcome.

On the same lines, Chris's abstract_dispatcher class
(not currently part of asio) would be useful as part
of the base lib.

Beyond that much of my review activity has focussed
on evaluating the threading system. Given that the 
threading system primarily exists to dispatch i/o events
back into application code i can't fault it from this perspective.

It provides an easily understood scheme for providing
thread(s) to the asio in which callbacks can occur. Comments
indicate that the mechanism used to trigger the callback
is very efficient. Perhaps this is at the cost of tight coupling
between the demuxer threading facilities and other
parts of the library, favouring high throughput apps
rather than customisability.

The locking_dispatcher in combination with the demuxer
offers some great ways isolate areas of code, or groups
of objects from eachother without having to do a lot
of explicit thread protection. I like it a lot.

The richness of behavour offered by the demuxer/locking_dispatcher/
boost::function/boost::bind combination really raises asio
to the level of an application-wide framework for asynchronous
programming, not just with i/o entities like sockets and files, but
with any technology that a programmer might need to
integrate into an app. Particularly what i mean here is that
its desirable to use the same demuxer-controlled threads
to do callbacks when events arise from those technologies
(e.g. legacy libraries that insist on calling back in their own
privately created thread). This would make available the same
pseudo-single threaded programming model throughout
the app.

Another factor is that for many apps (win32 GUI being
my favorite example) the programmer doesnt want
callbacks on a thread calling demuxer::run(), but on some
other special purpose thread that cannot be locked up
in the demuxer. This can be achieved in the win32 gui 
case using something comparable to a locking_dispatcher
that reflects the event into that thread by a windows message.
That however breaks the guarantees of the dispatcher 
concept ('callbacks will occur in a thread in demuxer::run()')
It may be an acceptable compromise, but perhaps 
the concept is too specific and tied to the implementation.

Anyway, the upshot of all this is i think that longer term 
the event dispatcher system in asio should be generalised 
into another library upon which asio should depend.
This library could be the basis of other asynch programming
efforts unrelated to i/o. It could offer more general
guarantees about what thread executes a callback,
and allow wider customisation than asio.

Thanks Chris for the excellent library, and
responding to my somewhat noisy posting. 

Cheers
Simon