[signals] connection death notification

Is there any mechanism in boost::signals that could provide notification when a slot/connection dies (is disconnected)? This functionality is needed to "chain" signals effectively. Imagine wrapping an existing signal-based library with a signal-based interface of some other type: a user connects to some signal on the wrapper, which then connects to some corresponding signal in the inner library. If the user disconnects from the wrapper's signal, the wrapper library would like to disconnect its associated connection to the inner library signal---but it has no way of knowing when the user's connection dies. Am I missing some trick that would give me this functionality? Would a patch implementing this functionality be accepted? Any suggestions for such an interface? -- Bryan Silverthorn <bsilvert@cs.utexas.edu>

On Mon, 2006-12-04 at 11:40 -0600, Bryan Silverthorn wrote:
Is there any mechanism in boost::signals that could provide notification when a slot/connection dies (is disconnected)?
This functionality is needed to "chain" signals effectively. Imagine wrapping an existing signal-based library with a signal-based interface of some other type: a user connects to some signal on the wrapper, which then connects to some corresponding signal in the inner library. If the user disconnects from the wrapper's signal, the wrapper library would like to disconnect its associated connection to the inner library signal---but it has no way of knowing when the user's connection dies.
Am I missing some trick that would give me this functionality?
I think it can be done... the slot can contain an arbitrary function object. When the slot is disconnected, that function object will be destructed (there might be a delay in the case of recursive signal calls). So if you had a shared_ptr stored in that function object, which pointed to something that disconnected the other connection when it was destroyed, you could get nearly the same behavior. There might be a slightly cleaner way using trackable objects and perhaps overriding visit_each in a clever way... but I'm not sure.
Would a patch implementing this functionality be accepted? Any suggestions for such an interface?
I'd definitely like to see what the interface would look like. This seems like generally useful functionality, but I'm a little nervous about making the Signals interface much bigger. Cheers, Doug
participants (2)
-
Bryan Silverthorn
-
Douglas Gregor