Skip to content
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

Add async DelayNs implementation for tokio. #109

Merged
merged 4 commits into from
Jan 25, 2024

Conversation

reitermarkus
Copy link
Member

No description provided.

@reitermarkus reitermarkus requested a review from a team as a code owner January 24, 2024 19:16
Copy link
Member

@eldruin eldruin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, thanks!

@eldruin eldruin added this pull request to the merge queue Jan 25, 2024
Merged via the queue into rust-embedded:master with commit 3ed5ad8 Jan 25, 2024
8 checks passed
@ryankurte
Copy link
Contributor

ryankurte commented Jan 28, 2024

hey fyi tokio::time::sleep is only good down to ms resolutions, for more granularity we typically need something nanosleep or a hot loop, so this implementation won't be accurate for anything less than a couple of ms.

having had to solve this a couple of times i suspect a more accurate way to do this would involve using epoll_wait with a timeout for > 1us delays (more accurate kernel timing than sleep is, particularly under the tokio runtime) and a hot loop over Instant::elapsed() for > 1ns delays (check elapsed and hit the waker every round).

possibly combining both into something like:

let now = Instant::now()
loop {
  // Grab elapsed at the start of the loop
  let elapsed = now.elapsed();

  // Break once we exceed the delay duration
  if elapsed > duration {
    break;
  }

  // Calculate the remaining sleep time
  let remainder = duration - elapsed;

  // epoll or spin depending on remainder
  if remainder > Duration::from_millis(1) {
    epoll_sleep().await;
  } else {
    spin_sleep().await;
  }
}

some folks do more complex things to balance accuracy and cpu use, but, this is fairly straightforward and would be closer to operating as intended.
(it's also good to keep track of elapsed times because there are reasons a sleep might end early, which has caused problems for me in the past)

@eldruin
Copy link
Member

eldruin commented Jan 29, 2024

Thank you @ryankurte! I have opened a new issue with your comment in #111.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants