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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-19 01:42:59

Frank Mori Hess wrote:

> I've just checked in some clean-ups, so the iterator doesn't keep a scoped 
> pointer to a lock anymore.  I changed lockNextCallable() so it uses the 
> locking form of blocked() and the iterator doesn't need any explicit 
> locking at all (correct me if I'm wrong).  Also, it allowed me to dump 
> that memory pool stuff that was trying to optimize dynamic allocation of 
> scoped locks.

Yes, the code looks much cleaner that way and the iterator memory
footprint is back within acceptable limits ;).

What I don't like about the release of all mutexes during the call
is that we lose the strong semantics of disconnect() and block().
We cannot guarantee anymore, that a slot won't be called after
disconnect() returned. That is a form of thread safety only the
library can provide.

Regards

Timmo Stange