From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-30 17:20:39
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 30 May 2008 16:24 pm, Anthony Williams wrote:
> Aha: it's the repeated waits that matter. For one wait it's O(N) in
> all cases. If you wait again on (almost) the same set, until the set
> is empty, it's an issue if you have to redo the set up, as that is
> then O(N^2) in total.
> That's a different use case to the one I imagined. I would call it a
> "future dispatcher" and have it invoke a callback on each future as it
> became ready.
Interesting, being able to attach a callback to such a future dispatcher would
actually make it possible for me to implement my scheduler. I also wouldn't
need to have a future_combining_barrier which can convert a heterogeneous
group of input futures into a result future of arbitrary type.
But I think I've finally figured out how to properly run the combiner in a
waiting thread as Johan has been suggesting, so I think I'm still going to
implement future_selector. It seems more powerful to return a future,
although the need does seem far more abstract now that I realize I don't
absolutely need the feature myself.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk