3 ms·

Is there any reason why one couldn't? stream::iter(0..10) .map(async_work) .map(|t| spawn(t)) .buffered(3 - 1) // The line above act as a

• demurgos 3y ago
  The poll_progress post linked above explains the situation. When polling the overall stream, you alternate between awaiting in the buffered interface or in the subsequent adapters. This is because the different futures are not peers with regard to the executor, but there's a chain of futures and `FilterMap` only calls `poll` on its parent when it's done with the current item. This post was also helpful to understand the issue: https://tmandry.gitlab.io/blog/posts/for-await-buffered-streams/ https://tmandry.gitlab.io/blog/posts/for-await-buffered-stre...
  • zamalek 3y ago
    I do understand the problem, I'm curious if spawn would resolve it. spawn (in the major executors at least) behaves as though it spawns a new thread to poll on. Therefore work does get underway even if callsite poll is never called, and the callsite only checks the status of the thread/task. https://tokio.rs/tokio/tutorial/spawning https://tokio.rs/tokio/tutorial/spawning