Douglas Paul Gregor <gregod@cs.rpi.edu> writes:
On Wed, 5 May 2004, Eric Niebler wrote:
We could be executing in Signal A and in Signal B simultaneously; then, slot c or d deletes object o (causing slots a, b, c, d to be disconnected). It's okay in Signal A--Signals was design for this--but can we be sure that Signal B won't fail?
I think I see the problem, but I don't know enough about trackable objects to say for sure whether it can be fixed. But it seems to be that in step (3i) below (which copies the slot into a local variable while the lock is still held) that the local variable should be able to keep a trackable object alive long enough to complete the slot call, even if it has been "deleted" in another thread.
It's really a user error we're trying to prevent. The user has said "delete o" when another thread is using "o" within a slot. The only way to stop the deletion is to acquire a lock in the destructor of a trackable object and wait until the call is done, but that's playing with fire :)
Standard prohibition applies: you can read any object from multiple threads, but if a thread is going to write it, no other thread can touch it for any purpose. I don't think you should try to "solve" this for Signals. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com