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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-24 14:18:45

Peter Dimov wrote:

>> I wasn't planning on dropping support for automatic tracking of signals, I
>> don't see that dropping it would make things any less confusing for the
>> user.
> 
> Automatic tracking is nice, but is it workable, if the goal is for the 'new' 
> signals to become part of the C++ standard library one day? It requires 
> cooperation from the function objects, and this is hard to achieve in 
> practice.

It's questionable if the whole idea of tracking through shared_ptr is
viable for a standardization effort. I of course have no experience
with this, but seeing what has been accepted into TR1, I'm a bit
sceptical about a TR2 signals and similarly "rich" functionality. It
would probably be better to not depend on the tracking anywhere, so
that it can be dropped altogether, if it turns out impossible to come
to an agreement.

This would mean we get rid of the specialized handling of signals
as a slot with automatic tracking (it comes cheaply with the pimpl
idiom, but that's an implementation detail). If the user does not
manage the connection and signal lifetime externally, they will have
to use track(). That's not a big problem in my opinion.

There is a bit of an ambivalence here, since we're still trying to
maintain compatibility to the current Boost.Signals. I would also
like to make the slot templated by the call signature instead of
the storage type (that's what Boost.Signals does) as you implied
in one of your examples. Otherwise the easiest way of determining
the slot type is through
        typename signal_type::slot_type
which is perhaps too inconvenient in that the exact signal type
must be known.

Regards

Timmo Stange