Special considerations

Multithreaded environments

Emiting signals is fully transparent in terms of multithreading, as it does not modify any state in signals theselves (nor managed_target derivatives).

On the other hand, mutating operations like creating/removing connections, destroying signals and automatically managed targets, must be serialized. msignals doesn't provide any synchronization mechanisms inside, as it would impose various overheads. However, the situation when such mechanisms would be required (e.g. access to the same signal from multiple threads) is considered as uncommon and being probably a symptom of a design error. You should provide implicit synchronization for signals and slots management, in other words avoid to operate on single signal from multiple threads. But as said above, you can still emit the signal from multiple threads as long as your slots are thread-safe.

Exceptions

Emiting signals is also fully transparent in terms of exceptions. But that means, if some slot throws an exception, it will propagate to the place where the signal has been emitted, interrupting further slot calling. It's not always desirable. On the other hand, there is no general way to determine correct reaction to an exception in place where the signal is activated. The signaling code could know nothing about possible slots and their exceptions. Therefore the best way is to avoid situation when any exceptions can propagate outside the slot.