Re: [boost] Boost.Signals deprecation and removal
Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says If you have existing [2]Boost.Signals-based code, it **will continue to work**, but consider moving to Boost.Signals2. Best Mike
References 1. http://Boost.Signals/ 2. http://Boost.Signals/
On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <boost@lists.boost.org> wrote:
Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says
"deprecated status may also indicate the feature will be removed in the future." https://en.wikipedia.org/wiki/Deprecation -- Olaf
On Thu, Jun 21, 2018 at 7:13 AM Olaf van der Spek via Boost < boost@lists.boost.org> wrote:
On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <boost@lists.boost.org> wrote:
Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says
"deprecated status may also indicate the feature will be removed in the future."
That's what deprecation means in the general case, but many, many open source projects and other organizations deprecate and then never remove things. It's not reasonable for everyone to have the same expectations for deprecation. All I mean by this is please be explicit. 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. Zach
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. Stefan -- ...ich hab' noch einen Koffer in Berlin...
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.
On 06/21/18 18:34, Zach Laine via Boost wrote:
On Thu, Jun 21, 2018 at 7:13 AM Olaf van der Spek via Boost < boost@lists.boost.org> wrote:
On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <boost@lists.boost.org> wrote:
> Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: > [1]Boost.Signals is no longer being maintained and is now
deprecated.
[...] No mention of removal. The documentation even says
"deprecated status may also indicate the feature will be removed in the future."
That's what deprecation means in the general case, but many, many open source projects and other organizations deprecate and then never remove things. It's not reasonable for everyone to have the same expectations for deprecation. All I mean by this is please be explicit.
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.
I can add that I did try using Boost.Signals2 in a multithreaded context, but ultimately its thread safety feature didn't help me as I had to implement external locking anyway.
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.
more recent benchmarks: https://github.com/NoAvailableAlias/signal-slot-benchmarks
participants (6)
-
Andrey Semashev -
Mike -
Olaf van der Spek -
Stefan Seefeld -
Tim Blechmann -
Zach Laine