On Saturday 17 May 2008 07:32, Johan Torp wrote:
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.
Returning a unique_future seems okay. To get around an exponential blowup in number of overloads when overloading each parameter for shared_future/unique_future you'd need some kind of implicitly convertible wrapper class. You could have future_barrier/future_switch accept and return a wrapper like the comb<T> from Braddock's library. The comb<T> could keep carry any state information which is needed to optimize the tree. Another solution would be to just provide another overload that accepts iterators to a user-supplied container of future<void>s. -- Frank