Anthony Williams-4 wrote:
One problem is wait_for_any is not sufficient to implement an efficient scheduler. You have to copy all the futures into wait_for_any so each wait_for_any call is O(N). So something like the future_selecter (should be spelled future_selector?) class I mentioned earlier would still be needed.
What do you mean by O(N) in this context?
You have N futures to wait for. You have to somehow register that you're waiting for each one => you need O(N) operations.
I suppose that if one of the futures was already ready, you could skip the rest, but that doesn't really strike me as much of an improvement.
Once it's done registering, wait_for_any then blocks until one of them is ready. No polling, just a single wait.
Could you elaborate on what you were getting at?
I think that it's a common use case to serve or ignore one ready future and then go back to waiting on the remaining ones. This would requrie O(N^2) with your interface. Johan -- View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-inte... Sent from the Boost - Dev mailing list archive at Nabble.com.