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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-29 13:24:29

On Thu, 29 Dec 2005 19:38:31 +0200
"Peter Dimov" <pdimov_at_[hidden]> wrote:

> Jody Hagins wrote:
> 
> > I'm sure there are many alternatives, but the first to mind (yet
> > probably undesirable), is to fork a process and use IPC mechanisms
> > and a very simple protocol in the absence of threading.
> 
> I'm not sure why is spawning a process and using IPC better than using
> a  thread. Is adding -lpthread to the command line that much to ask?
> Where's  the problem? 

If that's all it entailed, not it would not be too much to ask. 
However, several libraries in boost force multiprocessor functionality
on the user if the code is compiled with threaded ability.  A chief
offender is SmartPointer, made even more heinous because it is used all
over the place (no problem there -- I use it all over the place too).

Thus, if I compile one piece of code for multithreading, now all my uses
of shared_ptr<> and friends are going to require space for mutexes, and
worse, they are going to acquire/release locks for every operation.  The
only way around it is to compile completely without threads, which is
not what I want either.

One great advantage of C++ is that you can design libraries so that you
only pay for what you use.  However, several major boost components do
not adhere to this philosophy, at least not enough.

Thus, IMO, multithread support in some boost libs is just plain wrong. 
Some libs force you to use it all the time or not at all.  Very few
applications require full MT synchronization primitives for everything.

For this library, it even goes beyond that, I'm afraid.  The
demuxer::run() method always acquires/releases a mutex for each
operation.  I'm not sure where else it happens.