From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-06-02 12:41:23
Peter Dimov-5 wrote:
> The fundamental question is whether the layer you're calling should expose
> future<X> async_do_something( Y y );
> 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
> terms of the first, but I'm not quite sure that this is correct.
> 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
- 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
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
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?
-- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-interface-tp17242880p17605701.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