OK. I may or may not have time to finish the review, but here is the experience of my first use of the lib... I started at the beginning (i.e., Getting Started). I clicked on the Tutorial link, and followed it to the first example, timer1. While I have issues with the way timers work (mostly because it is just plain different), I wanted to build and run the first tutorial. I did not want to pollute my pristine boost installation, so I unpacked the stuff into a subdir, boost-asio-proposal-0.3.6, and set an environment variable ASIO_ROOT to point to the top. I then went to the tutorial source and tried to compile...
g++ -I${BOOST_ROOT} -I${ASIO_ROOT} -o timer timer.cpp
but I was rudely surprised to see the compilation fail with the following error... /home/jody/boost-asio-proposal-0.3.6/boost/asio/detail/mutex.hpp:25:3: #error Thread support is required! I was able to get it to build and run with this... g++ -I${BOOST_ROOT} -I${ASIO_ROOT} -D_REENTRANT -o timer timer.cpp -lpthread I find this highly problematic. I am not writing a multithreaded application, so why do I have to compile with threading enabled? If I am wrong, and there is some way to compile without threading, then you can ignore the following rant, as it applies to ASIO. However, it is still perfectly valid for the rest of Boost... This problem is further compounded because of the terrible way some Boost libraries treat threading. Some libraries (e.g., Boost.SmartPtr) embed mutexes in the objects based on compilation flags, and they ALWAYS run through the thread protection mechanisms. This is just crazy. I'm sorry, but there is no other way to put it. One of the objectives for asynchronous I/O is to reduce the dependency on multi-threaded concepts. However, here it is, tightly married to the wench. Maybe it is to do asynch resolutions or some other sort of system calls, but I still cry foul. Please do not take it wrongly, but at some point we MUST stop the madness. The boost philosophy is just plain wrong here. Libraries are saying that just because you compile with the ability to do multithreading, all parts of code pay the price, even parts that are not multithreaded. This library goes even further, by mandating that the application be built with threads enabled. I certainly hope that somewhere, after "getting started" there is some rationale. However, it would have to be pretty darn good rationale, because I can not seen any reason to allow a library to require threading (except, of course, the threads library).