Wasm support

[ghost]

I'm assuming a browser (javascript) environment. Quick thoughts:

• Async will be unusable because AsRawFd/AsRawSocket types don't exist on wasm.
• Timer can be perhaps be implemented by calling setTimeout() in javascript.
• Instead of running a thread-local or work-stealing executor, just spawn tasks through javascript.
• Blocking executor should either be normal spawn or panic.

[FuriouZz]

Hello there 👋🏾 I will be glad to help you with this issue!

[ghost]

@FuriouZz Thank you, help would be very welcome! :)

[Stupremee]

Imo blocking executor should just redirect to a normal spawn because it’s easier to convert current code to Wasm. But it should be mentioned in the documentation somewhere.

[ghost]

For reference, see wasm support in async-std: async-rs/async-std#757

[ghost]

@Stupremee Is the blocking executor even used on wasm? I would assume no since there are no files and no stdin/stdout/stderr on wasm, but I could be wrong?

[huangjj27]

I would assume no since there are no files and no stdin/stdout/stderr on wasm, but I could be wrong?

Maybe it's about WASI ? It would be glad to see WASI is also supported

[ghost]

@huangjj27 I believe WASI still in development and does not have what we need yet... hopefully soon :)

[jjl]

I've got a WIP PR #99 where i've started to implement this. At the minute, most things are basically commented out with cfg, but I've started some of the basic plumbing to get everything building.

There's plenty left to do, like actually call some javascript apis to spawn the task and work on e.g. Timer, but people seem interested in contributing from this thread, so I thought I'd start making things public early.

[fogti]

support for emscripten might be useful, too ((maybe) related: https://users.rust-lang.org/t/how-to-get-tcpstream-to-work-in-wasm/13103/6)... althrough I'm not sure how common emscripten usage is, as of today.

[kwek20]

This is still an issue for me @stjepang ; i'm running on windows with rust 1.47:
cargo run --example windows-uds --target wasm32-unknown-unknown
It will fail on nb-connect-1.0.2 which is missing socket imports from async-io-> winapi-rs

Ive given it a look but im lost in dependencies :) , any idea?

[notgull]

It's going to be difficult to implement this before atomics become stable for WASM runtimes. The main blocker is the parking crate. We could use setTimeout() to implement parking with timeouts, and maybe even some kind of Promise-oriented system where Unpark calls the resolve() callback. However, WASM has a threading proposal that simplifies this and avoids needing to call into JS at all. As a bonus, this would be able to run inside of WASI runtimes like Wasmer, instead of just inside of browsers.

However, both Wasmtime and Wasmer don't have the best support for atomics right now. When I run parking's tests in wasmtime, it complains of an env::memory module not being available. I'm unsure if this is an error with wasmtime or with Rust's code generation. I get even more cryptic errors when I try it in Wasmer.

[notgull]

With the exception of async-io (smol-rs/async-io#153), every smol crate that can realistically support WASM now supports WASM. I suppose that such WASM support can be exposed in this crate as well.

@smol-rs/admins Thoughts on exposing WASM support in this higher level crate?

[extraymond]

It would be nice to use smol in cloudflare worker!
They landed socket support which impl AsyncRead/AsyncWrite. This enables connecting to tokio-postgres, which is pretty cool.
https://github.com/cloudflare/workers-rs/blob/cfaabb5c021121a544c0981d05cf9317e4e03503/worker/src/socket.rs#L141

It would nice to compose futures around smol's local_executor in their wasm runtime, several of the worker-rs api are derived from web_sys and have async api around them.