Re: [boost] Re view Request: future library (N2561/Williams version)

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

-----BEGIN PGP SIGNED MESSAGE-----
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 
cvs:

http://www.comedi.org/cgi-bin/viewvc.cgi/libpoet/poet/future_waits.hpp?view=markup

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINJB25vihyNWuA4URAso5AKDgrKbSC7xLxMgav+dNB3PQsFSb6ACgmscf
jdiBKjmET32LjvRuAvyUXmw=
=UB2b
-----END PGP SIGNATURE-----