Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st

Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-02-19 09:59:22

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

On Wednesday 18 February 2009, Nat Goodspeed wrote:
> 1. visitor discovers plain pointer/reference to a subclass of my
> Trackable base class:
>
> Use Trackable to track the new connection.
>
> This is working now -- but as you point out, it's less safe than your
> slot_type::track() mechanism since a Trackable might be destroyed during
> a slot call.

There's also the fact that disconnect doesn't get called until the base class 
destructor (after the derived class destructors have already run).  Really, 
you might as well be using boost::signals2::trackable for this case, since it 
is equivalent to what you are doing (although I'd avoid this case entirely if 
you care about thread-safety).

> 2. visitor discovers a shared_ptr to something other than a Trackable
> subclass:
>
> This is the case I was asking about. My visitor can in fact pass the
> shared_ptr to slot_type::track(), but it's pointless because the
> shared_ptr copy stored in the boost::bind() result makes the referenced
> object effectively immortal.
>
> To my surprise, I find that it's not destroyed even when I explicitly
> disconnect the resulting connection.

It will get destroyed eventually.  The signal cleans up its slot list little 
by little during connect/invoke.  It doesn't immediately remove disconnected 
slots from the slot list since other threads might be using the same slot 
list concurrently.  It might be possible to make it immediately reset the 
shared_ptr owning the slot though, leaving an empty shared_ptr in the slot 
list, since that wouldn't invalidate any iterators.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmdc8oACgkQ5vihyNWuA4U8VwCgvK+rErMUtP458AKqcUhiKUPF
55oAn0GKKGMVKqc2C1CF1VkBE725XcSy
=bDoE
-----END PGP SIGNATURE-----