Corrade::Interconnect and thread-safety

[foodchaining]

An excerpt from Boost.Signals2 docs (Automatic Connection Management):

Unfortunately, the boost::signals::trackable scheme cannot be made thread safe due to destructor ordering. The destructor of an class derived from boost::signals::trackable will always be called before the destructor of the base boost::signals::trackable class. However, for thread-safety the connection between the signal and object needs to be disconnected before the object runs its destructors. Otherwise, if an object being destroyed in one thread is connected to a signal concurrently invoking in another thread, the signal may call into a partially destroyed object.

What about Corrade::Interconnect? How thread-safe is it?

[mosra]

This library is by design not doing any locking or other measures for thread safety, as that slows down single-threaded cases. The user is expected to handle this on the application side when needed, i.e. when touching shared data in signals/slots.

A different question is thread safety of slot execution. Qt's signal/slot implementation, for example, has a per-thread signal queue, meaning that a signal fired from one thread causes a slot to be executed in a thread belonging to slot's object (and not to signal's object). In my opinion such approach solves data races much better compared to extensive locking around or inside every signal/slot execution. It however makes the library implementation vastly more complicated and thus is not done here -- the target use case here is connecting arbitrary method calls within a single thread, suitable for example for UI code.

If you need guaranteed thread safety or advanced capabilities beyond the scope of this library, simply use either Qt's signal/slots or the one from boost. That's a completely valid (and encouraged) thing to do ;)

[mosra]

Closing due to lack of activity.