Re: [boost] asio review extended till Dec 30th

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-28 21:48:56

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