Boost logo

Boost :

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 );
> 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:
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:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at