From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-18 12:35:03
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