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 unexpected. 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 before mutex2; slot: scoped_lock l(mutex1); promise-fulfiller: scoped_lock l(mutex2); promise.set(100); // It is totally unexpected that this code will acquire mutex1 other thread: scoped_lock l(mutex1); scoped_lock l(mutex2); 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. 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.