Signals library safety
Hello to all, I'm looking into using the Boost.Signals. The library claims not to be thread safe. What does this mean exactly? When using Boost.Threads, can I make concurrent calls to connect as long as I wrap each call in a Mutex? If this is possible, do tackable objects also still work (if two trackable objects get destroyed in two different threads there might be a problem from what I understand) On an different note, I am trying to use Boost.Signals for network event handling. I'd like to set it up so that it uses something similar to he JavaScript event model, where every slot returns a boolean value. If that value is false, the remaining slots are not called. Would anyone have any recommendations on how to do this? Should I wrap each slot in a function that takes the return value and sets a global flag, then every subsequent slot checks the flag? It looks like combiners would not be appropriate, as it appears they are used after each slot is called (unless the InputIterator' opeator* actually calls the slot??) Thanks for any help -Eugene
When using Boost.Threads, can I make concurrent calls to connect as long as I wrap each call in a Mutex?
Sure, so long as you aren't connecting to the same signal at the same time.
If this is possible, do tackable objects also still work (if two trackable objects get destroyed in two different threads there might be a problem from what I understand)
Yes, that would be a problem. I don't think I would recommend using trackable objects in a multithreaded environment, because destruction of an object in one thread could interfere with, e.g., calling a signal in another thread. Wrapping a mutex around that would not be easy.
On an different note, I am trying to use Boost.Signals for network event handling. I'd like to set it up so that it uses something similar to he JavaScript event model, where every slot returns a boolean value. If that value is false, the remaining slots are not called. Would anyone have any recommendations on how to do this? Should I wrap each slot in a function that takes the return value and sets a global flag, then every subsequent slot checks the flag?
No need for that...
It looks like combiners would not be appropriate, as it appears they are used after each slot is called (unless the InputIterator' opeator* actually calls the slot??)
Combiners would be appropriate! operator* does actually call the slot, so you need a Combiner like this: struct _call_until { typedef void result_type; template<typename InputIterator> void operator()(InputIterator first, InputIterator last) const { while (first != last && *first) ++first; } }; My apologies for the slow turnaround time. Doug
participants (2)
-
Douglas Gregor
-
Eugene Talagrand