-----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=... 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-----