-
Notifications
You must be signed in to change notification settings - Fork 67
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
Web timer support #153
base: master
Are you sure you want to change the base?
Web timer support #153
Conversation
This commit moves the implementation for Async<T> into a new file called io.rs. This is done, as adding wasm32-unknown-unknown does not support async I/O, so it's easiest to move it all to another file to cut if off. As this commit will make up the majority of the lines of the overall PR, I've elected to make it separate for ease of review. Signed-off-by: John Nunley <[email protected]>
This commit moves the native Timer implementation into another file. The goal is to setup the ability to toggle between web-based and IO-based Timer implementations. Signed-off-by: John Nunley <[email protected]>
This commit adds support for async-io on wasm32-unknown-unknown. Not all features of async-io can be ported to WASM; for instance: - Async<T> can't be ported over as WASM doesn't really have a reactor. WASI could eventually be supported here, but that is dependent on smol-rs/polling#102 - block_on() can't be ported over, as blocking isn't allowed on the web. The only thing left is Timer, which can be implemented using setTimeout and setInterval. So that's what's been done: when the WASM target family is enabled, Async<T> and block_on() will be disabled and Timer will switch to an implementation that uses web timeouts. This is not a breaking change, as this crate previously failed to compile on web platforms anyways. This functionality currently does not support Node.js. Signed-off-by: John Nunley <[email protected]>
4ffc395
to
8b7c787
Compare
Signed-off-by: John Nunley <[email protected]>
This comment was marked as resolved.
This comment was marked as resolved.
Signed-off-by: John Nunley <[email protected]>
It probably does not work in Web Worker either. rustwasm/wasm-bindgen#1046 Also, there may be an issue mentioned here. tomaka/wasm-timer#21 (comment) |
The Prioritized Task Scheduling API is currently the solution to this problem, but is unfortunately only supported by Chrome so far, but Firefox is working on it. The nested call throttling of See the Winit implementation as an example:
This can be circumvented by providing your own bindings, e.g. I've done this in |
I would prefer having wider browser support. I'll add a note to the documentation for |
You can do runtime support detection, we have done this in Winit. |
This commit adds support for async-io on wasm32-unknown-unknown. Not all
features of async-io can be ported to WASM; for instance:
could eventually be supported here, but that is dependent on
WASI support? polling#102
The only thing left is Timer, which can be implemented using setTimeout and
setInterval. So that's what's been done: when the WASM target family is enabled,
Async and block_on() will be disabled and Timer will switch to an
implementation that uses web timeouts.
This is not a breaking change, as this crate previously failed to compile on web
platforms anyways.
This functionality currently does not support Node.js.
Closes #89