Re: [boost] [thread_safe_signals][signals2] call for reviewers (review tentatively scheduled Nov 1st - Nov 10th)

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

Hi Stjepan,

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