Status of thread safe signals?
What is the status of the thread safe signals library in sandbox/thread_safe_signals? Will it go in the main boost library at some point? Thanks Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 18 March 2008 07:09 am, James Talbut wrote:
What is the status of the thread safe signals library in sandbox/thread_safe_signals? Will it go in the main boost library at some point?
It's in the review queue. It needs to get a review manager, then have a review. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH38Tm5vihyNWuA4URAr9tAKCmz4m7J/HdfWYykTks64BNY2CubwCfbWIB VJFhIlrU84NdnESfFp5+icQ= =0z3T -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 18 March 2008 07:09 am, James Talbut wrote:
What is the status of the thread safe signals library in sandbox/thread_safe_signals? Will it go in the main boost library at some point?
It's in the review queue. It needs to get a review manager, then have a review.
Why does it require a review -- isn't this just an extension of an existing library? Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 18 March 2008 10:24 am, Jeff Garland wrote:
Why does it require a review -- isn't this just an extension of an existing library?
I'm not sure exactly where the threshold is for needing a review, so I'll just list some reasons it might need one. * There is an author change, and the new author (me) has never submitted a lib to boost before. A few of the headers in thread_safe_signals did start as copies of boost.signals headers, but it's mostly a new implementation. * The scheme for managing connections is different, people should probably have an opportunity to disparage it before it gets forced on them. There are also some new classes for supporting postconstructors/predestructors (which may not be needed after all, if I can get my changes to shared_ptr/enable_shared_from_this accepted). * It's not fully backwards compatible. I dropped the old connection management scheme (boost::trackable and visit_each) entirely. It could be made to be (almost) fully backward compatiible for source code, if that's deemed necessary. However, it's also been pointed out that now may be a good time to do some namespace and header location rearrangement to bring signals more into line with current boost policies. Actually, I'm already aware that some of my new classes (postconstructible/deconstruct_ptr/etc.) that I dumped into the boost namespace should be moved. It might be worth considering continuing to provide the old boost.signals library for a transition period, moving thread_safe_signals into a new namespace/header location entirely? * thread_safe_signals is header-only, boost.signals is not. I'm sure some people will see this as a change for the worse. In any case, I'm certainly not in a position to start ripping out boost.signals and replacing it with my code, until there has been some kind of review or blessing given to me to do so. Doug gave encouragment to embark on the project originally, but I don't think he's ever given any official stamp of approval to the final implementation. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH4AX+5vihyNWuA4URAi2EAJ9DvqLH06uQLVWx2n0aU+AT7DzZnACg1c46 Hw+BhZhKOnu41CX+Nel29fE= =sGfH -----END PGP SIGNATURE-----
On Mar 18, 2008, at 2:12 PM, Frank Mori Hess wrote:
On Tuesday 18 March 2008 10:24 am, Jeff Garland wrote:
Why does it require a review -- isn't this just an extension of an existing library?
I'm not sure exactly where the threshold is for needing a review, so I'll just list some reasons it might need one.
* The scheme for managing connections is different, people should probably have an opportunity to disparage it before it gets forced on them. There are also some new classes for supporting postconstructors/predestructors (which may not be needed after all, if I can get my changes to shared_ptr/enable_shared_from_this accepted).
* It's not fully backwards compatible. I dropped the old connection management scheme (boost::trackable and visit_each) entirely. It could be made to be (almost) fully backward compatiible for source code, if that's deemed necessary. However, it's also been pointed out that now may be a good time to do some namespace and header location rearrangement to bring signals more into line with current boost policies. Actually, I'm already aware that some of my new classes (postconstructible/deconstruct_ptr/etc.) that I dumped into the boost namespace should be moved. It might be worth considering continuing to provide the old boost.signals library for a transition period, moving thread_safe_signals into a new namespace/header location entirely?
These two are probably enough reason to hold (at least) a mini-review, especially because the natural way to integrate thread-safe signatures is to have it replace the Signals library entirely.
In any case, I'm certainly not in a position to start ripping out boost.signals and replacing it with my code, until there has been some kind of review or blessing given to me to do so. Doug gave encouragment to embark on the project originally, but I don't think he's ever given any official stamp of approval to the final implementation.
I think some kind of mini-review (say, 4-7 days) of the implementation and its interface changes, followed by a staged introduction of the new implementation over two Boost releases, would make the most sense for this library. - Doug
participants (4)
-
Doug Gregor -
Frank Mori Hess -
James Talbut -
Jeff Garland