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... Sent from the Boost - Dev mailing list archive at Nabble.com.