Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid starvation from FuturesUnordered::poll_next #2049
I'm unsure about this. Overall, I think we need some better way to address this issue globally, as this behavior is also an issue with every other kind of Future/Stream/asynchronous function. If a task has work remaining that can be done, it will never yield to the executor. Making every single looping combinator track a maximum poll count seems like a possibility, but it seems like the kind of practice we'd want some discipline around, rather than picking arbitrary integers which will stack exponentially (with this PR, the limit of leaf-future polls for a
Yup, I agree it's not ideal, which is why I also proposed tokio-rs/tokio#2160 as a more "complete" fix. I actually argued the exact same point about exponentials in the tokio Discord a few hours ago as a reason why we ultimately want a more global mechanism :p I do think we need a solution in the short run too though, as global preemption is probably something that will take longer to settle, and this is certainly an issue right now (for example, I am running into it in Noria as we speak).