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. 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 with a ThreadingModel parameter (I chose to put it there and not after SlotFunction, but that may change). It defaults to signals::single_threaded which results in non-thread-safe behaviour. When signals::multi_threaded is given as an argument, the signal should be thread-safe. That is for now completely untested, though ;). As I was curious about the call performance, I ran a simple test, successively connecting up to 4 slots to the signal and calling it 10000 - 10000000 times. Here are the results: # Calls CVS SBL SBNS SBNM 1 10000 0.005 0.003 0.001 0.002 1 100000 0.057 0.037 0.019 0.025 1 1000000 0.582 0.362 0.209 0.269 1 10000000 5.882 3.659 2.073 2.668 2 10000 0.007 0.004 0.002 0.003 2 100000 0.075 0.044 0.027 0.031 2 1000000 0.769 0.461 0.269 0.322 2 10000000 7.668 4.535 2.744 3.274 3 10000 0.009 0.005 0.003 0.003 3 100000 0.095 0.054 0.035 0.038 3 1000000 0.964 0.555 0.360 0.411 3 10000000 9.643 5.538 3.525 4.010 4 10000 0.011 0.006 0.003 0.004 4 100000 0.114 0.061 0.038 0.044 4 1000000 1.155 0.641 0.419 0.451 4 10000000 11.482 6.378 4.124 4.519 CVS = The current CVS HEAD version. SBL = The sandbox version with legacy support (named slots). SBNS = The sandbox version without legacy support, single-threaded. SBNM = The sandbox version without legacy support, thread-safe. I used Visual C++ 2005 Express SP1 with /O2 optimization on an Athlon X2 3800+ for these tests. Results are in seconds. The comparison to the original CVS version is not quite fair, as I used dynamic linking there and static linking for the rest of the tests. I just did it to make sure my code was not significantly slower. 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. As the new single-threaded implementation is somewhat faster than the one supporting named slots, I will add a signals::no_name type that can be used for the Group template argument when legacy support is enabled. That will result in the faster implementation being used without losing compatibility to existing code with grouped slots. Reports about problems with certain compilers and any kind of other input would be very appreciated. Don't judge too harshly on the code, I know it needs a lot of cleanup ;). Regards Timmo Stange