-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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) iD8DBQFIQG+o5vihyNWuA4URAu0xAJ9/SzdFOl7BiMITpMbT9W4QVV+YMQCgqZZ5 mCMjYnfdlHS0cmcBWwrZOII= =HhXC -----END PGP SIGNATURE-----