Use web-time for tokio::time::Instant on wasm32-unknown-unknown

[simlay]

Motivation

tokio::time::Instant and such dependencies compile for wasm32-unknown-unknown however when std::time::Instant::now() is called, it panics. This more or less renders, tokio::time::* useless as they rely on tokio::time::Instant::now() (which then panics in the stdlib):

• tokio::time::timeout
• tokio::time::sleep
• tokio::time::Instant

Solution

I've done my best to try and research the various PRs. This is related to #6178 and tangentially related to #4827.

The web-time crate is referenced in a few issues and is a "Complete drop-in replacement for std::time that works in browsers."

Tokio is a pretty critical crate in the rust ecosystem and I don't take adding a new dependency lightly. When looking the other top level tokio dependencies, there are just two crates of even remotely similar popularity (pin-project-lite and signal-hook) so this dependency is definitely on the lesser-popularity side. The author/maintainer (daxpedda) is a pretty common contributor to winit (where I first recognized the handle) and a bunch of wasm related projects so I think they're pretty responsible (we've not met, we just contribute to the same repos from time to time.)

This is a sibling PR to tokio-rs/tracing#2758.

cc: @daxpedda (hope you don't mind the tag)

There's still the issue that std::thread::sleep is unsupported for wasm which is the next problem. I figure it's good to see the interest level of these changes before getting too far into the weeds.

[Darksonn]

I was under the impression that std::time and std::thread::sleep works under some wasm targets, but not others. Are you able to clarify this?

[daxpedda]

cc: @daxpedda (hope you don't mind the tag)

I appreciate it actually, so I can help out if necessary!

I was under the impression that std::time and std::thread::sleep works under some wasm targets, but not others. Are you able to clarify this?

Both Emscripten and WASI support std::time.
std::thread is supported as well given the right environment and sub target, e.g. wasm32-wasip1-threads.

std::thread::sleep() specifically works on wasm32-unknown-unknown as well if compiled with target-feature= "atomics" (which requires -Zbuild-std).

This all depends of course on the environment. E.g. std::thread::sleep() will fail in browsers under wasm32-unknown-unknown if called on the main thread.

I'm not particularly familiar with Emscripten and WASI, but I'm happy to answer any questions around wasm32-unknown-unknown and browser support.

[Darksonn]

The current situation is that Tokio isn't really usable in browser wasm because it will block the UI thread when it goes to sleep. However, I believe it should work from web workers as blocking the worker is okay.

[simlay]

I don't love this solution but think it might be the least bad? I played with a few different refactors to deal with the Inner of Clock in the cfg_test_util feature block using std::time::Instant. I'm presume is for testing timeouts and such and really didn't want to touch it. I think using the same feature-flagged type alias might be the most maintainable.

Thoughts?

[Darksonn]

What cases does this actually improve the situation in? If it only makes a difference in non-web-worker browser-wasm, then I don't think it makes sense.

[Darksonn]

Ping on this?

[C0D3-M4513R]

What cases does this actually improve the situation in? If it only makes a difference in non-web-worker browser-wasm, then I don't think it makes sense.

I made an app using egui, and I am currently using this via the cargo patch section.
I chose to use tokio for my app, because tokio is my first choice for an async driver on native apps.

My web-app is only a "port" I made of my app.
This pr would actually help me in that situation.

I am unable to demonstrate the app currently because of some web CORS issues (so unrelated to this pr or crate).
I haven't tested my app with browser CORS disabled, but it should work to like 90% (I might have to revisit some persistence things, but again unrelated).

[simlay]

What cases does this actually improve the situation in? If it only makes a difference in non-web-worker browser-wasm, then I don't think it makes sense.

Yeah. After authoring this PR and using it more I ran into other issues and wish for more features from the time module. In the time since I authored this PR, I've been looking at how one could use gloo_timers to help with the things in tokio::time::{Interval, Interval, Sleep} but it's the APIs aren't very similar.

My web-app is only a "port" I made of my app.

Yeah, my use case is similar to @C0D3-M4513R's. I have an existing project which I'm trying to support running in the web browser. The existing codebase uses a lot of tokio::time::Instants and a few tokio::time::timeout()s. I've done this with other projects and ended up with similar hurdles.

I agree that it's pretty un-intuitive to be able to do tokio::time::Instant::now() yet unable to use tokio::time::sleep with it. I suppose we could punt/close this PR for now as it doesn't support the other portions of time.

I definitely tried to keep this PR small and straight forward. Would it be of interested to expand the scope to include Timeout, Sleep, and Interval?