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?