On: Rust Stream API visualized and exposed

[zamalek]

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 buffered slot
      .map(unwrap_join)
      .filter_map(async_predicate);

[demurgos → zamalek]

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-stre...

[zamalek → demurgos]

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