Douglas Paul Gregor 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. At the very least it should be possible to implement it such that a zombie trackable object can be detected so that calling a zombie slot has well-defined behavior.
3) slot_iterator::operator* does the following: i) copies the slot into a local
Might not actually need this step, because the slot itself cannot be deleted at this point.
I don't think you can skip this step. Consider the next two steps:
ii) releases the lock iii) calls the slot through the local
Imagine another thread nulls out the slot between (ii) and (iii). If you access the slot directly instead of through a local, you're in for trouble. And as I mentioned above, the local variable might be able to do some lifetime management for trackable objects.
What do you think?
Sounds very, very promising.
Excellent! -- Eric Niebler Boost Consulting www.boost-consulting.com