Re: [Boost-users] [signals] thread-safe post-disconnect() cleanup

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-24 11:00:17

On Friday 23 February 2007 07:01 pm, Peter Dimov wrote:
> Timmo Stange wrote:
> I was never particularly fond of providing dual components with
> thread-safe and "thread-unsafe" interfaces (for the various definitions
> of that.) The ideal scenario, in my mind, is to provide a single
> component that is still as overhead-free as possible in the
> single-threaded scenario. Unfortunately, the straightforward approach of
> copying a vector<shared_ptr> doesn't achieve that goal, but I _think_
> that it's possible to implement the same interface in a more efficient
> way, using copy on write and versioning tricks. Maybe Frank's
> implementation already does this.

Yes, it uses a shared_ptr to hold the slot list, and uses 
shared_ptr::unique() to decide if it really needs to make a new full copy 
of the slot list before adding/removing slots from the list.  Signal 
invocations are assured no slots will be added or removed from their slot 
list while they are running.  For a single-threaded usage pattern, the 
only situations it will make a new full copy in is if you call connect() 
or set_combiner() from a slot.

-- 
Frank