Tokio: Streams are not polled when added dynamically if pre-existing streams do not produce items

Created on 13 Mar 2020  路  2Comments  路  Source: tokio-rs/tokio

Version

0.2.13

Platform

macOS (Darwin L037 19.3.0 Darwin Kernel Version 19.3.0)

Description

When adding streams dynamically to StreamMap, the future returned by StreamExt::next() never becomes ready unless previously existing streams become ready. When looking at poll_next_entry it seems that it is never woken by addition of new streams (that are potentially already ready when they are added).

Here is a code sample, which times out because of this issue:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8d3f3eb8676b5046a5308c98ca273904

I'm not sure if my use of Mutex has anything to do with it (I use it because insert requires &mut self) or if it can also manifest itself in other situations...

A-tokio C-bug M-stream

Most helpful comment

Your code sample does not illustrate the issue: Line 21 will wait forever as the first async block is not releasing the lock until a message arrives, which doesn't happen until line 21 is passed. That said, the issue is real, and #2323 should fix it.

All 2 comments

Your code sample does not illustrate the issue: Line 21 will wait forever as the first async block is not releasing the lock until a message arrives, which doesn't happen until line 21 is passed. That said, the issue is real, and #2323 should fix it.

To be more specific, this happens when this sequence of events happen:

  1. The map is polled and returns Poll::Pending.
  2. A new stream is added to the StreamMap.
  3. The task goes to sleep, waiting for the former poll_next call to wake the task up.

This is not possible to hit without manually calling poll_next in user code through either poll_fn or manually implementing e.g. Future. Trying to reproduce the steps above with e.g. select! will call poll_next again after the item has been added, which will make the issue go away.

Because of this, and because of the more complicated implementation needed to support this, we have decided to close this issue as wontfix.

Was this page helpful?
0 / 5 - 0 ratings