Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-21 17:13:25

Hash: SHA1

On Saturday 17 May 2008 07:32 am, 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.

In case you're interested, I've just implemented future_barrier and
future_select (changed name from future_switch) free functions in libpoet

I didn't do any clever under-the-hood optimizations, only provided overloads
that accept 2 to 10 future<T> arguments, plus one that accepts first/last
iterators to a container of futures.
Version: GnuPG v1.4.6 (GNU/Linux)


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