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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-25 19:40:31

Peter Dimov wrote:

>> 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<signal_impl> 
> reformulation has the same effect, minus the possibility of a dangling 
> reference.

A signal would then rather be a handle object, or not? I wouldn't
see a problem in this if it were just for the invocation and
connection to another signal, but with member functions like
connect() and disconnect() it would appear like a rather unusual
construct to me.

> The next step is to have a shallow slot (shared_ptr<slot_impl>) 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.

When the user provided a reference to a function object for the slot
construction, the deep copy will still not give you a function with
its own state. Together with connects and disconnects being only
effective on one copy, this can become quite messy. What happens
to the connection objects returned by connect()? Do they only refer
to the original slot or also to every 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?

No, not really. I was only reminded of this by the idea of copyable
signals. It would be easy to split a signal into a connection managing
base and invocable subclass, so that the owner could just expose a
reference to the base for observers to connect to. I couldn't come
up with a proper name for that base class right now, though.

Regards

Timmo Stange