Johan Torp:
Interesting way of putting it. I was hoping we could do better than the second interface, that futures could solve a lot of the problems which are associated with that approach; - Exception propagation, as you pointed out - It does not allow detection that there are not futures associated with a particular promise, which has been proposed. - You need to handle safe and threadsafe shutdown from within the "done" callback, if the future-listening thread wants to terminate before the active object - It also suffers from all of the problem with moving functors/code from one thread to another. See my arguments regarding executing foreign thread's code at: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-inte... I guess most done-callbacks will be thin wrappers which does minimal things like posting a message containing the value but the problems are still there.
There's no question that the future-based interface can be safer and more convenient. But this doesn't necessarily make it "the" low-level interface on top of which one can (or must) express all other interfaces. The callback-based interface, on the other hand, can be difficult to use, but both future-based and message-based interfaces can be built upon it. A future-based interface built on top of a callback interface doesn't seem to suffer from the deficiencies you list, and neither does a message-based interface (given an appropriately powerful and robust message-passing framework in which to express it.)