Re: [boost] Re view Request: future library (N2561/Williams version)

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-26 19:57:51

On Monday 26 May 2008 16:13, Johan Torp wrote:
> I agree public slots are simpler and more powerful. IMO they are a lot
> more dangerous though. Some examples:
>
> If I connect a slot that might throw an exception, that exception will
> be thrown from the promise-fullfilling thread's set()-call. This is
> totally unexpected.

That's true.  However, the connect call of the future which connects a slot 
to the future-complete signal could return a future<void>.  The returned 
future<void> would either become ready if the slot runs successfully, or 
transport the exception the slot threw.  I think you could even make it a 
template function and have it return a future<R>, and let it accept the 
completed future's value as an input parameter.

> If a slot acquires a lock, it can lead to unexpected deadlocks if the
> promise-fullfilling thread is holding an external lock while calling
> future::set(). Assume you have two locks which you always should acquire

That is even more true when the callback code is run in future::get() or 
future::ready(), since the callback code will have to be run while holding 
the future's mutex (unless perhaps if it is a unique_future).  If the user 
callback code is run in the promise-setting thread, it can be done without 
holding any locks internal to the library.

> I don't know how common this particular example would be but I'm
> guessing there are lots of similar problems out there. Basically, you
> don't expect future::set to run a lot of aribtrary code. And if you do,

Is future::get or future::ready to running a lot of arbitrary code any less 
surprising?