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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-29 16:53:38

On Thu, 29 Dec 2005 22:42:29 +0200
"Peter Dimov" <pdimov_at_[hidden]> wrote:

> Right, and this can be a problem if shared_ptr is used only as an 
> implementation detail; implementation details shouldn't affect the 
> interface.

Right.  However, my main problem is that I don't have a choice if I use
shared_ptr (and some others).  I'm forced to use the synch prims even
when I know it's never needed.

> Specific undesirable effects (such as reduced performance) can be bad.
> 
> Synchronization, by itself, is not. It's merely a way (not the only
> way) to  implement the documented thread safety guarantee of ::run.

Right.  I am not belittling synchronization... only the use of it when
it is unnecessary.

> (One example of a specific undesirable effect that springs to mind is
> the  possibility of deadlock if a callback invokes ::run.)

Indeed.  I am firmly opposed to holding a lock across I/O operations,
and the code here holds the lock across many I/O operations.  I am
almost as opposed to holding them across callback functions.

> From a cursory look at epoll_reactor, I'd think that the costs of the
> lock  are negligible for the ST case (barring a pathologically
> inefficient mutex  implementation) since the critical regions are
> fairly expensive.

The CRs could be made a lot less expensive, and in this case, the sync
prims are probably not as bad.  However, the pattern of writing code in
this manner is what I'm really having problems with...

However, when you are processing many thousands of messages per second,
ANY extra unnecessary work becomes non-negligible.  Note that network
applications have inherent delays, so programmers of these beasts try to
remove everything possible.  It's even more important when your program
is "competing" with another program and you are already at a
disadvantage because of connection distance.  Every microsecond counts.

I *really* only want to pay for what is necessary.  If there are extra
bells, features, whistles, let me pay for them as I go.  This is the
main reason I do not use Boost.Signals any more.  All the additional
features have bloated the lean use case so much that I have found its
use impractical for high performance applications.