On Tuesday 30 January 2007 22:40 pm, Timmo Stange wrote:
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?
I hit the same problem, I had to manually disconnect at the beginning of my destructors, see http://article.gmane.org/gmane.comp.lib.boost.user/24356 Thread-safe automatic disconnect from non-static member functions seems like it would require some kind of extension to the language itself, like a pre-destructor. I recently did the same thing as you, my signals implementation is attached, if you are interested. The namespaces are different in my code, ::boost is ::EPG and ::boost::signals is ::EPG::signalslib. -- Frank