[boost] Asio formal review

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?
Enormous.

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

- 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 
'receive'.

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 
on POSIX?

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

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.

Matt