From: Eric Niebler (eric_at_[hidden])
Date: 2004-05-05 13:29:08
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.
-- Eric Niebler Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk