time: Clarify MissedTickBehavior documentation#7941
Open
chrisduerr wants to merge 1 commit intotokio-rs:masterfrom
Open
time: Clarify MissedTickBehavior documentation#7941chrisduerr wants to merge 1 commit intotokio-rs:masterfrom
MissedTickBehavior documentation#7941chrisduerr wants to merge 1 commit intotokio-rs:masterfrom
Conversation
Currently the missed tick behavior's text is not clear on whether the next tick after a missed tick will fire immediately, or if some behaviors could have the missed ticks ignored completely and wait until the next tick instead. The graphics and code examples already portray this correctly, but making this statement in plain text should hopefully clarify any potential confusion. This also removes the following section from the `Skip` behavior documentation: > unlike [`Burst`], the ticks may not be *one* multiple of `period` away > from the last tick. From my understanding, this comment is inaccurate. Neither burst nor skip are guaranteed to have ticks *one* multiple of period away from the last tick (it could be less for both). Both burst and skip also will never have ticks *longer* than one interval. Maybe this was a typo and it was meant to say `Delay` instead?
chrisduerr
commented
Feb 27, 2026
| /// at the next-closest tick that is a multiple of `period` away from | ||
| /// `start` (the point where [`Interval`] first ticked). Like [`Burst`], all | ||
| /// ticks remain multiples of `period` away from `start`, but unlike | ||
| /// [`Burst`], the ticks may not be *one* multiple of `period` away from the |
Author
There was a problem hiding this comment.
Just realized that this is most likely a typo and meant to say Delay when I wrote the commit message. If someone can confirm this I can change that rather than removing this section entirely.
chrisduerr
commented
Feb 27, 2026
| /// like [`Burst`], the ticks may be shortened to be less than one `period` | ||
| /// away from each other. | ||
| /// ticks remain multiples of `period` away from `start`. Like [`Delay`], | ||
| /// the number of fired ticks are no longer the same as they would have been |
Author
There was a problem hiding this comment.
Personally I think rephrasing this as "number of fired ticks" is an improvement compared to just "ticks are no longer the same", especially since a lot of this section talks about duration and not count.
That said, this was mostly a driveby idea I had for rephrasing things, I'm happy to discard if you disagree with this change.
Darksonn
added
T-docs
mattiapitossi
changed the title
MissedTickBehavior documentationMissedTickBehavior documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently the missed tick behavior's text is not clear on whether the next tick after a missed tick will fire immediately, or if some behaviors could have the missed ticks ignored completely and wait until the next tick instead.
The graphics and code examples already portray this correctly, but making this statement in plain text should hopefully clarify any potential confusion.
This also removes the following section from the
Skipbehavior documentation:From my understanding, this comment is inaccurate. Neither burst nor skip are guaranteed to have ticks one multiple of period away from the last tick (it could be less for both). Both burst and skip also will never have ticks longer than one interval. Maybe this was a typo and it was meant to say
Delayinstead?