From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-26 16:13:59
Frank Mori Hess-2 wrote:
> The thing is, this whole exercise started for me to see if it was possible
> to get rid of the public signal/slots on futures and replace it with just
> various waits on futures. Once we start adding callback functions to the
> future_select and future_barrier, which are executed on completion, it's
> really a sign of failure to me. I'd rather just leave the public slots on
> futures as that is simpler, more powerful, and no less dangerous.
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
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 in
some specified order to avoid dead-locks. Say you should acquire mutex1
promise.set(100); // It is totally unexpected that this code will acquire
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, you have coupled
the future-listeners and future-fulfillers in a very implicit way.
If futures are internal to a library such as poet it is fine. But to expose
a generic future-object with such an interface is far from optimal, IMHO.
-- View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29-tp16600402p17478481.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk