Re: [boost] boost::signal thread safety

From: "Philippe Vaucher" <philippe.vaucher@gmail.com> Subject: [boost] boost::signal thread safety (implied question: is boost::function thread safe ?) Well, the subject says it all ;) This question comes because boost::signal's documentation says it's not thread safe, but I have trouble finding exactly why it isn't.
Another issue that might be of concern is whether a slot is being disconnected from a signal in one thread while a value is being sent through that same signal in another thread. If the one thread is iterating through the connected slots while the other is removing a slot from the list, unexpected behavior/crash might occur. Doug said that some people have recently been working on Boost.Signals and specifically addressed thread safety, but I'm not sure what the status of that is. Regards, Stjepan

Stjepan Rajko wrote:
Doug said that some people have recently been working on Boost.Signals and specifically addressed thread safety, but I'm not sure what the status of that is.
There is a working implementation by Frank Mori Hess in the boost sandbox under thread_safe_signals and another (which is currently not working) by me under signals. The efforts are discussed on the users list and everybody is welcome to contribute. I actually think that's what we need most in the current situation as providing thread-safety seems to be the least of our problems ;). For a quick summary: everybody agreed on dropping the "trackable" base class design as it cannot be made thread-safe. Besides that, compatibility with the current Boost.Signals has been maintained, even though it stands in the way of optimal scalability and also complicates the implementation. Independent design questions seem to fade away as quickly as they're raised, because of the lack of additional input. Regards Timmo Stange

Timmo Stange wrote:
...snip... There is a working implementation by Frank Mori Hess in the boost sandbox under thread_safe_signals and another (which is currently not working) by me under signals.
The efforts are discussed on the users list and everybody is welcome to contribute.
Those development discussions would really be more appropriate on this list. The user list is intended to answer user level questions -- not for discussions of designs. I suggest you move the discussion here. Jeff
participants (3)
-
Jeff Garland
-
Stjepan Rajko
-
Timmo Stange