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

async-std@1.6-beta.1: wasm-timer Delay pauses #775

Closed
azriel91 opened this issue May 12, 2020 · 6 comments · Fixed by #776
Closed

async-std@1.6-beta.1: wasm-timer Delay pauses #775

azriel91 opened this issue May 12, 2020 · 6 comments · Fixed by #776

Comments

@azriel91
Copy link
Contributor

azriel91 commented May 12, 2020

Heya, e4df140 uses wasm_timer::Delay in src/utils.rs for WASM target's Timer implementation. When running a countdown async task in a loop with a 50 ms delay, it pauses for 4 seconds every 19 iterations (observed in both Chrome and Firefox):

delay_wasm_timer

Switching it to futures_timer::Delay allows it to loop smoothly:

delay_futures_timer

#776 has the change, though futures-timer depends on async-std in [dev-dependencies], so not sure if you'd like the somewhat cyclic reference.

futures-timer backs onto gloo_timers, which calls the browser's setTimeout API. I couldn't figure out how wasm-timer does it.

@dignifiedquire
Copy link
Member

Interesting, futures-timer was a dependency before in here, so this should be fine

@Fishrock123
Copy link
Member

Fishrock123 commented May 13, 2020

Perhaps there is some misunderstanding, but wasm-timer still uses javascript setTimeout.

The bug is probably due to this unwrap failing and defaulting to 5 seconds: https://github.com/tomaka/wasm-timer/blob/master/src/timer/global/wasm.rs#L60

I'm considering trying to work on optimizing futures-timer, given the information above is there any reason to use wasm-timer?

@azriel91
Copy link
Contributor Author

Perhaps there is some misunderstanding, but wasm-timer still uses javascript setTimeout.

ah, I didn't grep the wasm-timer repository; did human-eye file traversal, and gave up because I went too far down the (wrong) rabbit hole.

I like futures-timer's simplicity. If deciding whether or not to use wasm-timer, one would have to:

  • understand the value the additional complexity provides
  • figure out why that unwrap is failing

@tomaka
Copy link

tomaka commented May 18, 2020

Author of wasm-timer here:
To create wasm-timer I took what was futures-timer at the time and changed "the backend".

The reason why I didn't do it the way futures-timer 0.3 does is because the public-facing API at the time was exposing the Instant and Interval types. I had to expose a custom version of Instant, and Interval is quite complicated to implement.

Nowadays there's no good reason to use wasm_timer anymore.

@tomaka
Copy link

tomaka commented May 18, 2020

Additionally, wasm_timer was a quickly written "hack" to make existing code compile. Like many hacks, it stays there longer than it should.

@dignifiedquire
Copy link
Member

thank you @tomaka both for your hacks and the info 👍

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 a pull request may close this issue.

4 participants