[signals2][review] The review of the signals2 library (formerly thread

headers Frank Mori Hess | 18 Jan 17:34

On Friday 16 January 2009 16:35, Nat Goodspeed wrote:
> Johan Råde wrote:
> > Frank also mentioned the possibility of adding
> > a thread safe version of boost::trackable
> > based on boost::enable_shared_from_this.
> > That would be a very valuable addition to the library.
>
> Second that! While I love the generality of the explicit tracking, I've
> been jumping through some hoops trying to adapt existing Boost.Signals
> code that uses boost::trackable.
>
> If signals2 could provide a thread-safe version of boost::trackable, it
> would make conversion a much easier "sell" within my organization.

I have added a thread-UNsafe boost::signals2::trackable to svn to ease 
porting of single-threaded Boost.Signals code that doesn't need to be made 
thread-safe.  

Would you give a little more detail on what parts of boost::trackable 
porting you've found the most painful?  Because to get thread-safe 
connection management in any form you'd still have to make your objects 
owned by shared_ptr and deal with the "no shared_from_this() in 
constructors" issue, since I don't think the release version of 
enable_shared_from_this supports use in constructors yet.

With respect to the "no shared_from_this() in constructors" issue, I've 
added a "deconstruct" factory function based on make_shared and Michael 
Marcin's make_shared_access patch.  It constructs the shared_ptr with a 
single allocation like make_shared and calls 
postconstructible::postconstruct like deconstruct_ptr.  Its use can be 
forced by making your constructors private and declaring the class 
boost::signals2::deconstruct_access a friend.

Re: [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st