Boost logo

Boost Users :

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-----


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net