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

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-27 05:46:12

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

You would need to return a connection too so that you can disconnect. And
after a wait-for-any composition has become ready, how would you know which
of all the connected slots you need to check for an exception? I think that
having a composite future in which the exception appears is a more natural
interface. 

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

Do you really need to hold the future's mutex while doing the evaluation?
Can't other threads just see it as not_ready until the evaluation is
complete and one of the future-listeners call future::set() or
future::set_exception() on the composite future?

Frank Mori Hess-2 wrote:
> 
> Is future::get or future::ready to running a lot of arbitrary code any
> less 
> surprising?
> 

IMHO, yes. The future-listeners are the ones which set up the lazy
evaluation so they should be prepared for it. Just like condition_variable's
predicate wait. If you set up a composite future and then share it to other
future-listening threads, you can state that this future can throw this and
that or does xxx. The promise-fulfiller OTOH should be de-coupled from what
it's listeners are doing.

Johan
-- 
View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17486842.html
Sent from the Boost - Dev mailing list archive at Nabble.com.