On Thu, 29 Dec 2005 22:42:29 +0200 "Peter Dimov" <pdimov@mmltd.net> 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.