On Sunday 11 February 2007 01:48 am, Timmo Stange wrote:
The modified version of Boost.Signals in the sandbox now compiles and passes the tests on my setup. Basic thread-safety is also in there, minus tracking and the combiner/signal-to-signal connection issues that have been discussed here recently.
Ack! You're pulling ahead of me :) I've just got to the point where I'm about to start going through the tests with thread_safe_signal. A bit of a redundant effort, I know, but once I got it to where I was planning to drop it, it seemed so close to being done. Better to have two thread-safe implementations than zero, I suppose.
The thread-safe version will not support grouping and naming of slots, so there is a preprocessor flag "BOOST_SIGNALS_NO_LEGACY_SUPPORT" which changes the template signature of signalN. If defined, the Group and GroupCompare parameters are replaced
I didn't really follow exactly why you decided to drop Group and GroupCompare. I was able to implement support for them pretty trivially in thread_safe_signal (see thread_safe_signals/detail/slot_groups.hpp and the connect() functions in thread_safe_signals/detail/signal_template.hpp).
The overhead for thread-safety does not grow with the number of connected slots, as I use a per-signal mutex and no per-slot locking. That looks good here, but I'm not yet sure it is the best solution in the long run. It would be nice to not block the entire signal for the whole time.
thread_safe_signals should be able to do multiple signal invocations concurrently, as well as disconnect and connect concurrently with invocation, due to my much-maligned per-slot locking :) and some other trickery. If you benchmark thread_safe_signals though, be sure to do it with multiple slots connected and multiple threads on a multicore cpu so its benchmark results look nice and inflated :) However, you should be able to get concurrent signal invocation even with a single mutex once boost supports a recursive_read_write_mutex, right? -- Frank