Boost logo

Boost :

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

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.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at