Gottlob Frege wrote:
It seems that now that we drop locks before running slots, we can get by with using boost/detail/lightweight_mutex.hpp for our mutex. Since it is header-only, and apparently compiles to a null mutex if the compiler is in single-threaded mode, I don't see much need for a ThreadingModel template parameter on the signal class any more. I'm dropping it from thread_safe_signals.
What if I want to use a single-threaded signal in a multi-threaded program? ie some of my signals are multi-threaded, but I also have some signals (for UI updates?) that will only ever be on the main/UI thread.
Yes, same here. I also would like to set deferred notification (through a message queue) on top of signals where that is advised for performance reasons. There are several scenarios in which you can ensure the thread- safety externally and use a single-threaded signal. On the other end of the scale I considered offering two different multi- threaded policies, of which one would serialize signal invocations and the other would allow them concurrently. Regards Timmo Stange