Re: [Boost-users] [signals] thread_safe_signals feature-complete

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

On Saturday 17 February 2007 02:21 pm, Timmo Stange wrote:
> Timmo Stange wrote:
> > The localConnectionBodies is a shared pointer to the actual
> > slot list and not a full copy, so I don't understand how this
> > is going to be thread-safe against concurrent invocations. The
> > mutex is released after this compound statement and the
> > invocation traverses a list that might be modified by the
> > "nolock_cleanup_connections(false);" in a concurrent call to
> > the same function.
>
> Sorry, I missed the use_count() check even though I quoted it ;).
> So concurrent invocation was a bad example, but what about other
> concurrent modifications of the slot container, like connect()?

connect also checks use_count() after locking the slot list mutex.  It 
calls nolock_force_unique_connection_list(), which creates a (expensive, I 
know) new copy of the slot list if it is already in use.

> Another thing: The original signal is safe against deletion from
> a slot invocation context. That's why it uses pimpl-Idiom.

Hmm, I didn't consider that case.  Since I've already got the pimpl there 
for signal tracking, I suppose I just need to create a local copy of the 
shared_ptr pimpl to prevent it from destructing in mid-invocation.

-- 
Frank