[Boost-users] [signals2] Usage (lifespan) question

Subject: [Boost-users] [signals2] Usage (lifespan) question
From: Nat Goodspeed (nat_at_[hidden])
Date: 2009-03-05 11:44:08

I'd like suggestions for an API designed around Boost.Signals2. This 
isn't performance-critical.

Assume a publish class containing a boost::signals2::signal. This 
class's listen() method is a thin wrapper around signal::connect(). 
Using boost::bind, I can listen() with any method (with appropriate 
signature) on any class.

I'm trying to introduce the concept of filter objects. Each filter is 
itself a publish object. Client logic composes a chain from some publish 
object through zero or more filters to the ultimate listener. A filter 
passes along to its own listeners some subset of the input notifications.

The central issue is the lifespan of a filter object. I want the filter 
objects in such a chain implicitly freed when the ultimate listener 
disconnects.

Approach 1
==========
I could achieve that by managing each filter object with shared_ptr, 
storing a copy in each listener. When the last listener is destroyed, 
the filter goes away. (This assumes passing weak_ptr to boost::bind() so 
the connection itself doesn't keep the listener alive. Further assume 
I've used connection::track() so that the signal to which the filter is 
connected implicitly disconnects.) Naturally this effect cascades 
"upstream" through the filter chain.

But it bothers me that such an implementation imposes new requirements 
on each listener. Beyond declaring a method with the right signature, 
the listener must now store a shared_ptr to the publish object to which 
it's listening. That implies a method on the listener to capture the 
shared_ptr and establish the connection. Therefore, every listener must 
be derived from some particular base class, and explicit connection and 
disconnection must be done through the listener rather than directly 
through the publish object.

Either this new inverted API must apply to all publishers/listeners, or 
client logic must distinguish between the case of connecting to a filter 
and connecting to any other type of publish object.

It feels to me as though this approach has gone into the weeds.

Approach 2
==========
Instead of passing a filter's weak_ptr to boost::bind() to the publish 
object's listen() method, I could instead pass the filter's shared_ptr. 
Now the publish object upstream from the filter is responsible for the 
filter's lifespan: when the filter explicitly disconnects, it will 
(eventually) go away. It will not implicitly disconnect because it won't 
go away as long as the connection still holds a copy of its shared_ptr.

(Frank says[1] he might tweak the library to forget a shared_ptr 
immediately on disconnect, but currently it survives for a while.)

Consider a chain:

A is the original publish object
B is a filter listening to A
C is the ultimate listener, listening to B

Again, the goal is to disconnect B (thus deleting it) when C disconnects 
or is destroyed.

We could make B store its connection object to A. The question is, how 
would B know to disconnect it? How could B become aware of C 
disconnecting from B's signal object?

Approach 3-n
============
Suggestions? Thanks!

[1] 
http://www.nabble.com/Re%3A--signals2--review--The-review-of-the-signals2-library-(formerly-thread_safe_signals)-begins-today%2C-Nov-1st-p22102367.html