Boost logo

Boost Users :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-02-23 14:23:50


Frank Mori Hess wrote:
> -----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.

You're right, this is a problem with the second form. It can be avoided by a
slight modification in the syntax:

signal.track( p ).connect( bind( f, p.get() ) );

or, with some bind syntactic sugar added:

signal.track( p ).connect( f, p.get() );

The slot-based formulation could look like:

signal_type::slot_type( bind( f, p.get() ) ).track( p ).connect_to(
signal );

or

signal_type::slot_type( f, p.get() ).track( p ).connect_to( signal );

Both seem passable, the first alternative looks a bit more natural. The
second has the advantage of potentially producing a reusable slot class that
can operate without a signal (if we get its interface right).


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