Re: [boost] Boost.Signals deprecation and removal

Subject: Re: [boost] Boost.Signals deprecation and removal
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-06-21 16:22:52

On 06/21/18 18:51, Stefan Seefeld via Boost wrote:
> On 06/21/18 11:34, Zach Laine via Boost wrote:
>> I'd like to point out that Boost.Signals2 is threadsafe, and you pay for
>> that, to the tune of 2x slower performance than Boost.Signals.  That is the
>> figure reported during the Boost.Signals2 review.  Does anyone know if this
>> has changed?  If not, removing Boost.Signals is a case of requiring some
>> users to pay for what they do not use (the threadsafety bit).  I never used
>> signals/slots in any context in which I was signalling across thread
>> boundaries, and I don't expect that to be a common use case.
> 
> Then that's a very good argument to parametrize Boost.Signals2 (in some
> way; there are many projects that use tricks to add thread safety
> without incurring performance overhead for the single threaded case) so
> you don't pay for something you don't need. I don't think that this
> should be an argument to keep an incompatible and deprecated API around.

There is a template parameter of mutex type in the `signal` template. 
You will still have to pay for `shared_ptr`, though.