Peter Dimov-5 wrote:
The fundamental question is whether the layer you're calling should expose
future<X> async_do_something( Y y );
or
void async_do_something( Y y, function<void(X)> done );
Obviously, in a message-passing-based architecture, the second interface would be more convenient as it allows you to just post an appropriate message in 'done'.
The "completion callback" approach tries to express the second interface in terms of the first, but I'm not quite sure that this is correct. Expressing the first in terms of the second seems more natural to me.
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. The alternatives A-F which I listed in my previous post assumes interface 1. It's about trying to "marry" different architectures with futures. I was hoping futures could be used as in interface 1 given any architecture you might have - but it seems difficult. Does this seem like a reasonable goal? Do you have any comments on the alternatives A-F in my previous post? Or any thoughts regarding the problems I listed with executing foreign threads' code? Johan -- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-inte... Sent from the Boost - Dev mailing list archive at Nabble.com.