[boost] Boost.Signals deprecation and removal

[James E. King, III via Boost]

This first implementation of signals has been deprecated since the 1.54
release. (When) are we going to remove it? It is under management of the
CMT, and it has been deprecated for over 10 major releases. I would like
to suggest we remove it in the Boost 1.68.0 release.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of James E. King, III via Boost
> Sent: 27 May 2018 19:22
> To: bo...@lists.boost.org
> Cc: James E. King, III
> Subject: [boost] Boost.Signals deprecation and removal
>
> This first implementation of signals has been deprecated since the 1.54
> release. (When) are we going to remove it? It is under management of the
> CMT, and it has been deprecated for over 10 major releases. I would like
> to suggest we remove it in the Boost 1.68.0 release.

This is probably overdue, but

I think I recall a consensus for a 'warning - notification of removal' at least one release before it happens.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830

[Tim Blechmann via Boost]

> This first implementation of signals has been deprecated since the 1.54
> release. (When) are we going to remove it? It is under management of the
> CMT, and it has been deprecated for over 10 major releases. I would like
> to suggest we remove it in the Boost 1.68.0 release.

i had been working on one project, that was never migrated from signals
to signals2, as attempts to migrate miserably failed: compile times
significantly increased and the msvc linker would run out of memory.

this project is currently migrated away from boost.signals (1 and 2) to
a more lightweight solution (nod signals), but i can imagine that there
are some projects out there which still use signals(1) and which would
run into trouble when it will be removed completely.

otoh i wonder if signals1 causes much maintenance overhead, that
justifies potentially breaking downstream code

[David Sankel via Boost]

On Tue, May 29, 2018 at 11:11 PM, Tim Blechmann via Boost <
bo...@lists.boost.org> wrote:

> > This first implementation of signals has been deprecated since the 1.54
> > release. (When) are we going to remove it? It is under management of
> the
> > CMT, and it has been deprecated for over 10 major releases. I would like
> > to suggest we remove it in the Boost 1.68.0 release.
>
> i had been working on one project, that was never migrated from signals
> to signals2, as attempts to migrate miserably failed: compile times
> significantly increased and the msvc linker would run out of memory.
>
> this project is currently migrated away from boost.signals (1 and 2) to
> a more lightweight solution (nod signals), but i can imagine that there
> are some projects out there which still use signals(1) and which would
> run into trouble when it will be removed completely.
>
> otoh i wonder if signals1 causes much maintenance overhead, that
> justifies potentially breaking downstream code

A standard response to something like this is that you can maintain the
Boost.Signals 1 library from within your own repository even as it gets
removed from Boost.

-- David

[mike via Boost]

> -----Original Message-----
> From: Boost <boost-...@lists.boost.org> On Behalf Of David Sankel
> via Boost
> Sent: Friday, June 8, 2018 2:40 PM
>
> On Tue, May 29, 2018 at 11:11 PM, Tim Blechmann via Boost <
> bo...@lists.boost.org> wrote:
>
> > > This first implementation of signals has been deprecated since the 1.54
> > > release. (When) are we going to remove it? It is under management
> of
> > the
> > > CMT, and it has been deprecated for over 10 major releases. I would
> like
> > > to suggest we remove it in the Boost 1.68.0 release.

As Paul suggested, I'd also vote for giving a removal warning for
1-2 release cycles first, but then remove it.

> >
> > i had been working on one project, that was never migrated from signals
> > to signals2, as attempts to migrate miserably failed: compile times
> > significantly increased and the msvc linker would run out of memory.
> >
> > this project is currently migrated away from boost.signals (1 and 2) to
> > a more lightweight solution (nod signals), but i can imagine that there
> > are some projects out there which still use signals(1) and which would
> > run into trouble when it will be removed completely.
> >
> > otoh i wonder if signals1 causes much maintenance overhead, that
> > justifies potentially breaking downstream code
>
>
> A standard response to something like this is that you can maintain the
> Boost.Signals 1 library from within your own repository even as it gets
> removed from Boost.

+1.

>
> -- David
>

Mike

[Olaf van der Spek via Boost]

On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost <bo...@lists.boost.org> wrote:
> As Paul suggested, I'd also vote for giving a removal warning for
> 1-2 release cycles first, but then remove it.

Isn't deprecation the warning?

--
Olaf

[Mike via Boost]

> 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/

[Olaf van der Spek via Boost]

On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <bo...@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

[Zach Laine via Boost]

On Thu, Jun 21, 2018 at 7:13 AM Olaf van der Spek via Boost <
bo...@lists.boost.org> wrote:

> On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <bo...@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

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

[Stefan Seefeld via Boost]

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...

[Andrey Semashev via Boost]

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.

[Andrey Semashev via Boost]

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.

[Tim Blechmann via Boost]

> 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

[Paul A. Bristow via Boost]

> -----Original Message-----
> From: Boost [mailto:boost-...@lists.boost.org] On Behalf Of Olaf van der Spek via Boost
> Sent: 20 June 2018 09:06
> To: bo...@lists.boost.org
> Cc: Olaf van der Spek
> Subject: Re: [boost] Boost.Signals deprecation and removal
>
> On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost <bo...@lists.boost.org> wrote:
> > As Paul suggested, I'd also vote for giving a removal warning for
> > 1-2 release cycles first, but then remove it.
>
> Isn't deprecation the warning?

Yes, but not a serious 'you've got to do something next release' warning ;-)

A removal warnings in this upcoming release notes?

(I think you can still sneak a 'docs' item into this pending release's notes?)

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830

[John Maddock via Boost]

>> Isn't deprecation the warning?
> Yes, but not a serious 'you've got to do something next release' warning ;-)
>
> A removal warnings in this upcoming release notes?

Even better - put a #pragma warning in the headers to say that it's
going to be imminently removed.

John.

---
This email has been checked for viruses by AVG.
https://www.avg.com

[Emil Dotchevski via Boost]

This is for Boost.Signals as opposed to Boost.Signals2, I suppose?

[James E. King III via Boost]

On Fri, Jun 22, 2018 at 2:49 PM Emil Dotchevski via Boost <
bo...@lists.boost.org> wrote:

> This is for Boost.Signals as opposed to Boost.Signals2, I suppose?
>
>

Correct, this is for Boost.Signals. I am going to add a release note to
1.68.0 indicating that Boost.Signals
will be removed in an upcoming release and folks should migrate to
Boost.Signals2. Signals was deprecated
in 1.54.0 (about 5 years ago).

- Jim