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