Re: [Boost-users] [signals] thread-safe post-disconnect() cleanup

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-23 18:07:23

Peter Dimov wrote:

> The slot_call_iterator idiom is another thing that I don't like in the 
> original Signals design; it feels too clever for its own good, and is there 
> to support a nice way of using combiners. I've nothing against combiners per 
> se, but the majority of the signal uses do not involve slot returns or 
> combinations thereof.
> 
> If I had to redesign the library, I'd explore a simple void operator() that 
> just calls the slots, and a separate
> 
>     template<class Cm> void call_and_combine( Cm & cm, ... );
> 
> that calls cm( s( ... ) ) for each slot s.

That's what the documentation describes as the "push method" and
is probably also with what I had come up with as a combiner solution,
mostly because I personally wouldn't use combiners that often.

The complexity issue mentioned in the docs would get another aspect
with thread-safe signals, because handling concurrent invocations
(which your further suggestions would allow easily) won't be that
simple when the combiner isn't aware of the context of a slot result.

> My initial iteration of this hypothetical design would also incur several 
> shared_ptr/intrusive_ptr copies on operator() to address the thread safety 
> issues in the most obvious "snapshot" way, that is, the signal invokes the 
> slots that were connected at the time operator() was called. Subsequent 
> concurrent modifications to the slot container do not affect the invocation 
> in progress. This has the advantage of being highly scalable and 
> deadlock-resistant.

True. It would also simplify Frank's implementation, I think, which
already uses copy-on-write semantics to handle the same problems from
a different angle.

As much as I like your ideas, I lack the confidence to actually move
into such directions. I take the current interface as the well-con-
sidered and matured design, which we should stay compatible with and
build on, even though the implementation admittedly looked a little
scary at first.

> Such an approach may turn out to not be acceptable, though, given that the 
> majority of signal benchmarks place heavy emphasis on operator() calls. 

I sense some bitterness there ;). I think we have some freedom
especially with the thread-safe implementation. Correctness and
scalability always come first in that area for me.

Regards

Timmo Stange