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

Timmo Stange wrote:

Peter Dimov wrote:

...

You don't need tracking for the above example; bind( slot, _2, _1 ) stores a copy of slot. Signals currently need tracking because they're noncopyable and are bound using ref(). A copyable signal does not, regardless of the semantics of the copy (deep, shallow, or something in between - deep for the signal, shallow for the contained slots).

How would such a copy behave regarding connect() and disconnect()? Neither should affect the original signal, so this would be either a deep copy or an implementation with copy on write semantics.

A shared signal is mostly equivalent to the current noncopyable signal, except that it's less inconvenient and less unsafe. Currently you are forced to use references or pointers to the signal, and every entity that posesses such a reference can connect() and disconnect(). A shared_ptr reformulation has the same effect, minus the possibility of a dangling reference. The next step is to have a shallow slot (shared_ptr) but a one level deep copy in the signal (vector<slot>). In this case connects and disconnects will only affect the copy, although the sharing at the SlotFunction level may still be undesirable at times. Immutable SlotFunctions would handle sharing (and concurrent calls) fine, of course; only stateful function objects will have a problem. A fully deep copy (vector< function<> >) avoids any sharing, but makes the signal quite expensive to copy.

I already don't like the fact that there is no distinction between control over connections and control over invocation. Every entity that is allowed to connect to a signal can also emit it, unless you provide a separate connect() yourself and hide the actual signal.

Is this a problem in practice?