[boost] Re: signals and threads

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.
> 

Excellent!

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com