-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tokio::time::Interval::poll_tick(...)
scheduling a wake-up even when returning Poll::Ready(...)
?
#5551
Comments
I agree that we shouldn't schedule a wakeup in that case. If somebody wants to submit a PR for this, then please go ahead. |
Alright thank you for confirming, I am on it 🙂 |
When `tokio::time::Interval::poll_tick()` returns `Poll::Pending`, it schedules itself for being woken up again through the waker of the passed context, which is correct behavior. However when `Poll::Ready(_)` is returned, the interval timer should be reset but not scheduled to be woken up again as this is up to the caller.
When `tokio::time::Interval::poll_tick()` returns `Poll::Pending`, it schedules itself for being woken up again through the waker of the passed context, which is correct behavior. However when `Poll::Ready(_)` is returned, the interval timer should be reset but not scheduled to be woken up again as this is up to the caller. This commit fixes the bug by introducing a `reset_without_reregister` method on `TimerEntry` which is called by `Intervall::poll_tick(cx)` in case the delay poll returns `Poll::Ready(_)`.
@Darksonn I have only used I am also wondering - could this change break some users which unwittingly relied on this behavior? 🤔 |
When `tokio::time::Interval::poll_tick()` returns `Poll::Pending`, it schedules itself for being woken up again through the waker of the passed context, which is correct behavior. However when `Poll::Ready(_)` is returned, the interval timer should be reset but not scheduled to be woken up again as this is up to the caller. This commit fixes the bug by introducing a `reset_without_reregister` method on `TimerEntry` which is called by `Intervall::poll_tick(cx)` in case the delay poll returns `Poll::Ready(_)`.
When `tokio::time::Interval::poll_tick()` returns `Poll::Pending`, it schedules itself for being woken up again through the waker of the passed context, which is correct behavior. However when `Poll::Ready(_)` is returned, the interval timer should be reset but not scheduled to be woken up again as this is up to the caller. This commit fixes the bug by introducing a `reset_without_reregister` method on `TimerEntry` which is called by `Intervall::poll_tick(cx)` in case the delay poll returns `Poll::Ready(_)`.
When `tokio::time::Interval::poll_tick()` returns `Poll::Pending`, it schedules itself for being woken up again through the waker of the passed context, which is correct behavior. However when `Poll::Ready(_)` is returned, the interval timer should be reset but not scheduled to be woken up again as this is up to the caller. This commit fixes the bug by introducing a `reset_without_reregister` method on `TimerEntry` which is called by `Intervall::poll_tick(cx)` in case the delay poll returns `Poll::Ready(_)`.
When `tokio::time::Interval::poll_tick()` returns `Poll::Pending`, it schedules itself for being woken up again through the waker of the passed context, which is correct behavior. However when `Poll::Ready(_)` is returned, the interval timer should be reset but not scheduled to be woken up again as this is up to the caller. This commit fixes the bug by introducing a `reset_without_reregister` method on `TimerEntry` which is called by `Intervall::poll_tick(cx)` in case the delay poll returns `Poll::Ready(_)`.
Version
Platform
Linux 5.14
Description
Reading the documentation of
Interval::poll_tick(...)
, it only states that a call topoll_tick(...)
will schedule the task to receive a wake-up when the call returnsPoll::Pending
. I would understand this implicitly as "The task will not be scheduled for wake-up when we returnPoll::Ready(...)
". However it looks like that the task is scheduled to be polled again even when returningPoll::Ready(...)
. I noticed this today when building something with an interval.While you could argue that this behavior makes sense for a periodic interval, I want to make sure that it is expected, otherwise something built on top of this might break some day. If it is expected, I am happy to submit a PR to update the documentation accordingly.
Below is an example to reproduce the behavior.
Cargo.toml
:The output looks like this:
If
Interval::poll_tick(cx)
did not schedule the task for being polled again when returningPoll::Ready(...)
, I would expect the stream to stall. Instead, it yields item as if someone scheduled for a wake-up.The text was updated successfully, but these errors were encountered: