Frank Mori Hess wrote:
If we want to support dynamically adding futures to future_switch and maybe future_barrier a free function won't suffice.
Yes, you're right. Especially with future_switch there should be a way to wait on a group of futures whose number is only known at runtime.
Hmm, actually what I said is wrong. As I believe has been pointed out before by others on this list, you could build up a arbitrary size group of futures to wait on at runtime by taking the return value from the free future_barrier or future_switch function and passing it to another call. So I'm still partial to the free function approach. It is similar to operator|| and operator&& in Gaskill's library except not operators, no comb<T> class or op() function, and overloaded to accept more than 2 arguments:
It is possible, what I meant by "won't suffice" is that it will be very innefficient. Imagine implementing or for 1000 futures. If you have "collection" you can just add children and get a tree with depth 2 and where the root node has 1000 childs. If you rely on free functions, say of arity 2, you get a tree depth of a 1000 and need 999 extra parent nodes which all has one leaf node and one of the parent nodes as child. Frank Mori Hess wrote:
future<void> future_barrier(const future<void> &a1, const future<void>& a2, ... , const future<void> &aN);
future<void> future_switch(const future<void> &a1, const future<void>& a2, ... , const future<void> &aN);
A naive implementation would probably be pretty inefficient when evaluating a future that has been produced after passing through many future_barrier/future_switch calls. But I imagine some optimizations could be found under the hood in the implementation to avoid unnecessarily long chains of futures depending on each other.
This would be nice and could potentially solve the inefficiency problem. You are allowed to wait for any node in a tree. The main difficulty is figuring out which nodes only exists in the tree and which who are visible to the outside world. The nodes who only exist in the tree can be re-arranged into a compact tree. Maybe we can use unique_future to guarantee this. I.e. the combination functions always return unique_futures and if we get these as in-parameters, we can safely re-arrenge the tree. 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.