Boost logo

Boost :

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

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