Re: [Boost-users] [signals] Automatic connection management and MT

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-03 18:28:02

Frank Mori Hess wrote:

> But what if someone creates a large number of short-lived connections and 
> relies entirely on our new automatic connection management scheme, never 
> explicitly calling disconnect()?  If the signal is only rarely invoked, 
> the number of dangling connections with invalid weak_ptrs will accumulate, 
> unless you check for them in connect().

Good point. I generally do not like garbage collection behaviour, but
it seems unavoidable here. A specialized smart pointer could allow for
direct notification when an object goes out of scope, but that would
again have the effect that all of the code has to be aware of the
trackability (either through intrusive_ptr and a trackable base class
again, or through direct use of a pointer type for exclusive use
in the signals system).

> It's not late at all.  I'm not committed to basing a full implementation on 
> my code.  I thought it would be a useful working prototype for exploring 
> ideas while trying to clarify design issues.  Whether it ultimately makes 
> more sense to do the full implementation starting from boost.signals, or 
> to try and graft the missing pieces from boost.signals onto the prototype 
> is an open question.

I took Boost.Signals, removed grouping, naming and tracking
(which are together responsible for more than half of the code)
and added rudimentary threading support with a single
recursive_mutex. I didn't want to spam the list with several
kB of compressed code, so I put it here:
   http://www.sepulchrum.com/sources/mt_signals.tar.gz

I kept the respective namespaces and hope that doesn't pose a
problem for testing.

What may be interesting to look at is that it works without
dangling connections at all. A disconnected slot is always re-
moved from the signal as soon as possible. That also simplifies
the overall code, but doesn't solve the problem you describe
above.
The signal cannot be called concurrently with this design, as
I've claimed before would be desirable, but I realized that it
is complicated with non-trivial combiners anyway.

Regards

Timmo Stange