Boost.Signals deprecation and removal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost.Signals deprecation and removal

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of James E. King, III via Boost
> Sent: 27 May 2018 19:22
> To: [hidden email]
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Tue, May 29, 2018 at 11:11 PM, Tim Blechmann via Boost <
[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list


> -----Original Message-----
> From: Boost <[hidden email]> 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 <
> [hidden email]> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Mon, Jun 18, 2018 at 10:12 PM, mike via Boost <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
   > 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/

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Thu, Jun 21, 2018 at 7:13 AM Olaf van der Spek via Boost <
[hidden email]> wrote:

> On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <[hidden email]>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
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...
   


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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 <
> [hidden email]> wrote:
>
>> On Thu, Jun 21, 2018 at 1:44 PM, Mike via Boost <[hidden email]>
>> 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.

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Olaf van der Spek via Boost
> Sent: 20 June 2018 09:06
> To: [hidden email]
> 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 <[hidden email]> 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





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
This is for Boost.Signals as opposed to Boost.Signals2, I suppose?

On Fri, Jun 22, 2018 at 8:25 AM, Paul A. Bristow via Boost <
[hidden email]> wrote:

>
>
> > -----Original Message-----
> > From: Boost [mailto:[hidden email]] On Behalf Of Olaf
> van der Spek via Boost
> > Sent: 20 June 2018 09:06
> > To: [hidden email]
> > 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 <[hidden email]>
> 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
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Signals deprecation and removal

Boost - Dev mailing list
On Fri, Jun 22, 2018 at 2:49 PM Emil Dotchevski via Boost <
[hidden email]> 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

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