On 1/30/07, Timmo Stange
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?
What if the signal held a weak_ptr to the slot-object? Before calling, it turns it into a shared_ptr, and voila, you won't get deleted during the call? Tony