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

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-03 11:40:22

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 02 February 2007 19:24 pm, Timmo Stange wrote:
> Frank Mori Hess wrote:
>
> [...]
>
> > Then any slots with expired weak_ptrs could be cleaned up
> > when the signal is next emitted, or also in signal::connect() to
> > prevent lots of dead connections from accumulating.  If we do cleanup
> > in connect(), then I could get rid of the disconnect callback stuff I
> > added, since it would be mostly redundant.
>
> As I mentioned in my reply to Peter Dimov, the current Boost.Signals
> implementation solves this from the call and disconnection context only.
> A limited number of dangling connections is not a problem and as this
> approach only prohibits direct removal of connections from the call
> context (with the same cleanup of dead connections that you already
> do), the problem I described does not exist.

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().  I also lean towards checking in 
connect instead of disconnect because it makes my implementation simpler.  
If you cleanup in disconnect(), the connection has to call back into the 
signal to tell it to clean up.  Then you have to take steps to be sure the 
lifetime of the callback doesn't exceed the lifetime of the signal.  There 
are no such worries when doing cleanup in connect(), since it's all inside 
the signal and the connection isn't involved.  The only disadvantage is 
the signal tends to store 1 more dead slot if cleanup is not done at 
disconnect.

> Is there a special reason you started from scratch instead of using
> Doug's implementation as a starting point? 

No, I probably had similar reasons as you did when you were considering 
implementing thread-safe signals as a stop-gap until the real thing became 
thread-safe.  I didn't understand the existing implementation, and my 
ambition was only to implement the minimum I needed for myself.  It was 
just a sidetrack while putting together a little active object framework 
I'm working on.  I couldn't trust the thread-safety of the code without 
understanding it, so I figured it would be quicker for me to implement the 
little core I needed than to learn the whole thing and try to tweak it.  
And I assumed making the real boost.signals thread-safe was not something 
that could be done in a few days, otherwise someone else would have 
already done it.

> I know I may come a little 
> late with this, but most of it seems to be reusable for a thread-safe
> version.

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.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFxLr35vihyNWuA4URAgTbAKDd3+14M6MCx/hUL9Pu4bo03OVntwCbByME
VLJ2uXDqRDPXbSkqnPH3Ym8=
=gW7r
-----END PGP SIGNATURE-----