From: Timmo Stange (ts_at_[hidden])
Date: 2007-01-30 22:40:58
I'm working on a preliminary solution for an interface-compatible
but thread-safe implementation of Signals for my project so that I
will be able to switch to Boost.Signals should Doug Gregor find
the time to add thread-safety there.
While deciding what parts to include and which to leave out, I
noticed that the automatic connection management is probably not
usable in a multi-threaded context in the current form. Using a
base class destructor (signals::trackable) to monitor an observer's
lifetime is bound to result in race condition trouble with the order
of destruction in a class hierarchy.
Has that been discussed somewhere and are there any proposed
solutions/alternatives?
Regards
Timmo Stange