On 11/02/2015 11:22, Gottlob Frege wrote:
It sounds like Nigel has convinced Nevin that for a hypothetical thread-safe + non-thread-safe "Signals3", we could/would do it the right way.
FWIW, existing Signals2 already does it the "right way", if I'm following the conversation properly. By default Signals2 gives you thread-safe signals, but if you want non-thread-safe signals you merely need to supply a dummy mutex template parameter. Thus both implementations can co-exist without any ODR violations or magic #defines. (And you can use some alternate mutex type if you wish, which I have found useful on occasion.) It's possible that this limits some further performance optimisations that could be done if you know that the mutex is a no-op -- but if someone cared to make those optimisations it could be done easily enough as a template specialisation without affecting anything else. (Having said that, it could be an interesting exercise to make a Signals3 that uses non-blocking atomic operations instead of mutexes where feasible. I'm not sure how much benefit there would be in real-world software though.)