[boost] [thread_safe_signals] reviving boost::trackable?

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-06-12 10:12:43

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

It's occurred to me that thread-safe automatic connection management for 
signal/slot connections made in an object's constructor to one of its member 
functions could be accomplished by using a boost::trackable class that looks 
like

class trackable: public enable_shared_from_this<trackable>
{
//...
};

Above, I'm only requiring the "classic" enable_shared_from_this functionality, 
no special support for shared_from_this in constructors, etc.

You would derive from trackable, visit_each would discover it inside bind 
objects, and its destructor would disconnect its associated connections, 
similar to how the current signals library works.  It would do a bit more 
though.  When the signal is invoked, it would:

1) check that the connection has not been disconnected.  If not, it calls 
shared_from_this() to obtain a shared_ptr which can be used for connection 
tracking in the usual thread_safe_signals way.  Calling shared_from_this can 
be made safe since the trackable destructor (which disconnects) will be 
called before the enable_shared_from_this destructor.

2) if the shared_ptr from shared_from_this is empty, that means the trackable 
object is either in the process of being destroyed, or hasn't been passed to 
an external shared_ptr owner yet.  In either case, the slot is skipped by the 
signal invocation.

However, there is a downside to this and other schemes where the signal/slot 
connection is made in the constructor but blocked until the object is passed 
to an external shared_ptr.  In a common use case, an observer will connect to 
an observed object's signal and then manually query the observed object once 
to get its initial state.  It can then rely on the signal to keep in sync 
with any changes the observed object undergoes.  If the signal is blocked 
until the observer is owned by an external shared_ptr, it raises the 
possibility of the observer getting out of sync with the observed, since a 
signal could occur and be missed after the manual query of the observed 
object's initial state.  So, doing all the connection setup in a 
postconstructor still seems preferable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIUS7c5vihyNWuA4URAhPIAKC40cK1kgX9o7aPYILBaHZu3jwZhQCfYFjw
o/drv0EOsHqvEt+7exy/PDo=
=Lj6m
-----END PGP SIGNATURE-----