Re: [Boost-users] [signals] thread-safe default combiner

From: Doug Gregor (dgregor_at_[hidden])
Date: 2007-02-09 16:18:31

On Feb 9, 2007, at 3:21 PM, Timmo Stange wrote:

> Frank Mori Hess wrote:
>
>> I'm noticing now that boost::last_value isn't thread-safe when  
>> used with a
>> non-void return value, since a thread can't in general be sure the  
>> signal
>> will have any slots connected to it when it is invoked.  Would it be
>> acceptable to make last_value throw an exception on the non-void,  
>> no slots
>> case?  Throwing an exception seems preferable to the dreaded  
>> "undefined
>> behaviour".  Or we could use a slightly modified default combiner  
>> with a
>> different name.
>
> Returning an Optional if T is default constructible seems like
> a viable refinement of that solution. I'm a little uncomfortable
> with exceptions being thrown potentially everywhere along the
> call chain as a default behaviour.

The problem is that we don't get to return an optional, because the  
return type is specified as "T", not "optional<T>".  And,  
unfortunately, we can't rely on there always being a default  
constructor there.

Right now, the implementation is allowed to crash if you call one of  
these signals and there are no slots. Throwing an exception brings  
some sane defined behavior to something that is now completely  
undefined.

If we could reliably detect default-constructibility, we might be  
able to come up with something better.

        Cheers,
        Doug