Re: [boost] Status of thread safe signals?

From: Doug Gregor (dgregor_at_[hidden])
Date: 2008-03-27 14:04:58

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