Subject: Re: [boost] [thread_safe_signals][signals2] call for reviewers (review tentatively scheduled Nov 1st - Nov 10th)
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2008-10-14 09:11:25
Stjepan Rajko wrote:
> * Relationship to Boost.Signals:
> This is a thread-safe variant of the original Boost.Signals library.
> There have been some changes to the interface to support
> thread-safety, mostly with respect to automatic connection management.
> The following thread offers some more details on the differences
> between the two implementations, as well as a plan of a phased
> replacement of Boost.Signals should Signals2 be accepted:
> http://tinyurl.com/4sqau3 [nabble]
It might be more expeditious to directly paste Frank's points from his
email in the above thread. I've pasted them below. Is the intent to only
review these changes?
It might help if there were a summary section on the diffs with this new
version. Glancing over the documentation it wasn't clear where to find
the differences other than the section mentioned above for Automatic
Connection Management. Are there examples demonstrating new usage
patterns? Is there any info on the cost of this thread safe
implementation vs. the signals1 in a single threaded application?
--- * 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. --- Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk