Enabling time causes panic on wasm32-unknown-unknown target

[edusporto]

Version
tokio v1.25.0

Platform
Linux 5.10.161-1-MANJARO x86_64
Chromium Version 109.0.5414.74 (Official Build) Arch Linux (64-bit)

Description
I've been trying to implement a platform-independent asynchronous game loop with a fixed amount of time between each game tick for an NES emulator with tokio.

Enabling the time feature and building a simple application like the following causes the program to panic:

fn main() {
    tokio::runtime::Builder::new_current_thread()
        .enable_time()
        .build()
        .unwrap()
        .block_on(run());
}

async fn run() {}

The panic's trace as can be found in my browser's console is the following:

nes_bg.wasm:0x86d9d1 Uncaught (in promise) RuntimeError: unreachable
    at __rust_start_panic (nes_bg.wasm:0x86d9d1)
    at rust_panic (nes_bg.wasm:0x864816)
    at std::panicking::rust_panic_with_hook::hd000e9fb43b5781d (nes_bg.wasm:0x6be509)
    at std::panicking::begin_panic_handler::{{closure}}::he16e52e9a7dddeb1 (nes_bg.wasm:0x737911)
    at std::sys_common::backtrace::__rust_end_short_backtrace::h227361e053771d9e (nes_bg.wasm:0x85e4c9)
    at rust_begin_unwind (nes_bg.wasm:0x7ef4f0)
    at core::panicking::panic_fmt::h9d972fcdb087ce21 (nes_bg.wasm:0x8419d5)
    at std::time::Instant::now::h48900f1b4f732c12 (nes_bg.wasm:0x827e48)
    at tokio::time::clock::now::h93e60839152994b2 (nes_bg.wasm:0x7acd00)
    at tokio::time::clock::Clock::now::h0da3e36115821256 (nes_bg.wasm:0x7cfc46)

I'm using cargo run-wasm (https://github.com/rukai/cargo-run-wasm) to get the program running.

I'm not sure if I should flag this issue as a bug or a feature request; it seems like Wasm support hasn't been implemented for the time feature yet, but I haven't been able to find any issues tracking this situation's status.

Taking a quick look at the panic trace, I think the bug comes from the usage of std::time::Instant::now, which apparently panics on Wasm platforms. Something like https://github.com/sebcrozet/instant could be used to fix this, although it doesn't seem to be actively mantained.

I'm a beginner in tokio, but I could try to help solve the issue in case it's not too complicated.

Thanks!

[Darksonn]

I don't know how much we can do about this. Our wasm support is pretty limited, and we only support timers when you're using a wasm platform that supports them.

I guess we could catch the panic so that we do not fail until someone tries to actually use a timer.

[zt1106]

same problem here, tokio Instant depends std Instant which is not available in wasm32-unknown-unknown

[Darksonn]

Tokio does not require a timer. If you're on a platform that doesn't support timers, then you shouldn't enable the time feature of Tokio.

[pickfire]

Shouldn't it error at compile time to prevent it from even compiling instead of having an error at runtime?

[temeddix]

I also have issues with this, since using tokio::time::sleep is very common. It would be so nice if we could use this on wasm environments.

[temeddix]

I think we can refer to the idea from this repo: https://github.com/tomaka/wasm-timer

But the thing is, are we allowed to make pull requests that use some JavaScript crates, such as js_sys and web_sys?

[Darksonn]

Tokio isn't going to support that at this time. Making the runtime usable in wasm environments where you're expected to yield out of wasm would require a completely separate runtime implementation from what Tokio does today.

[temeddix]

Yeah, I'm aware of the fact that in many cases, we yield out of wasm to go back to Javascript world.

However, there are also cases where tokio runtime is occupying a web worker with its own business logic(without yielding), which means tokio running in wasm does has its uses. Actually, without the feature time enabled, we were able to run tokio runtime in the browser in its own 'web worker'.

IMHO providing basic support for wasm, including tokio::time, might allow tokio go to the next level.

[Darksonn]

To my knowledge, it is not possible to support timers in a web worker without yielding entirely out of wasm when sleeping.

[Darksonn]

Closing as working-as-intended. We do not currently have any support for wasm platforms where we cannot block. We may add that feature in the future (and you could file a feature request for that), but this issue is a bug, and the fact that we don't have a specific feature is not a bug.