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