From: David Abrahams (dave_at_[hidden])
Date: 2004-05-05 19:51:10
Douglas Paul Gregor <gregod_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk