Re: [Boost-users] [signals] thread-safe post-disconnect() cleanup

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-23 14:00:18

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

On Friday 23 February 2007 13:38 pm, Peter Dimov wrote:
> Frank Mori Hess wrote:
> > Would you elaborate on the race you are thinking of?  Putting track
> > in the connection class instead of the slot class makes races
> > possible, since the connection is established before the tracked
> > objects are added. Admittedly, this is only a problem if you are
> > holding the tracked objects as weak_ptrs before giving them to the
> > signal.
>
> This isn't very likely since you won't be able to use coord->x if you
> only have a weak_ptr. Typically you'll lock() and connect if that
> succeeds. The temporary shared_ptr will ensure that there is no race.
> This is easy to enforce if track() takes a shared_ptr instead of a
> weak_ptr.

After I've thought about it a bit more, it is worse than that.  Suppose an 
invocation starts before you add your shared_ptr for tracking.  It will 
lock all the tracked weak_ptrs (but not the one you haven't added yet of 
course) before running the slot.  Then, the thread making the new 
connection adds its shared_ptr for tracking and moves on, its local copy 
going out of scope.  Then, the signal invocation continues and executes 
the (now possibly bad) slot without ever knowing about the tracked object.

My personal preference is now near where I started out:  a single-argument 
signals::track() function for the common case, and a track() member 
function of the slot class for adding an arbitrary number of arbitrary 
tracked objects.  I don't like that the two-argument signals::track() 
limits the number of tracked objects to the number of bound arguments, or 
that it unnecessarily couples them to particular arguments.

> The singalslib::track race occurs if you have
>
> T* get_pointer( something_like_weak_ptr<T> p )
> {
>     return shared_ptr<T>( p ).get();
> }
>
> There is a small window where it's possible for the weak_ptr to expire
> while the caller of get_pointer is holding a T*.

That doesn't effect thread_safe_signals, since it won't run the slot except 
while it is already holding shared_ptrs to all the tracked objects.

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

iD8DBQFF3znD5vihyNWuA4URAgD6AKDJVZk2r9aDCCFKOVe6VKE4IQKOgACeP8s0
q0oRLluCKEXyaptKsQFiO4M=
=yIK8
-----END PGP SIGNATURE-----