Re: [Boost-users] [signals] sandbox version status

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-02-11 09:32:48

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