Document what parts of Tokio can be used without its runtime

[surban]

Is your feature request related to a problem? Please describe.
I'd like to use functionality from Tokio without using its runtime, particularly I'd like to use functionality from tokio::sync (channels, locks), tokio::io (traits and utils without stdio) and tokio::time with an executor targeting WebAssembly.

Describe the solution you'd like
It is currently not documented if these modules require using the Tokio runtime or if they can be used with any async runtime.
I'd like to see official documentation whether that use case is supported.

Describe alternatives you've considered
I could try and experiment, but I would like a statement from the developers what is supported officially.

Alternatively it would be great if Tokio could provide a runtime that works on WebAssembly, even when limited at first, e.g. single threaded. I am not asking for WebAssembly support for tokio::net or tokio::fs, only a runtime that supports Tokio's synchronization primitives and allows building WebSocket support (browser provided) on top of it.

[Darksonn]

Anything in tokio::sync is executor-independent and will work anywhere. The traits in tokio::io and most utilities are also executor-independent, but things like tokio::io::stdin and tokio::io::unix::AsyncFd are not. The tokio::time module requires using a Tokio runtime.

Regarding having Tokio work on web-assembly, it's somewhat unclear what that would even mean. In wasm, you don't actually have a traditional runtime, as the actual runtime is your browser.

[surban]

Thanks, that helps a lot.

From a user perspective Tokio's executor supporting WebAssembly would mean that things like tokio::spawn and tokio::task::spawn_blocking work, even if they just forward the tasks to the browser for execution. This would make porting crates depending on Tokio to spawn tasks much easier. I don't know enough about Tokio internals, but would it be possible to implement something in that direction?

[Darksonn]

We are open to expanding WASM support beyond the executor independent pieces if we can find a good way to do it. I don't know enough about WASM to know what it would take, and I do not have the bandwidth to drive the feature myself.

I don't think a method like spawn_blocking could ever exist in WASM-land, but making tokio::spawn work is probably possible.

[surban]

Maybe I will have a look myself what can be done since I will require some decent async support for a project.

What is the case against spawn_blocking assuming that WASM workers are enabled? It should still be possible to start a thread pool and dispatch work to it.

[Darksonn]

I opened #4240 to elaborate on the channels.

Maybe you can get spawn_blocking to work with web workers. I don't know anything about it really.

[mxgrey]

Would the tokio maintainers consider spinning the sync module off into a separate tokio-sync crate and then re-importing it to the tokio crate as the tokio::sync module?

I have a situation where I would love to be able to use the various tokio channel implementations but don't actually need the tokio runtime. My understanding (...which I admit could be wrong...) is that a crate is a single unit of compilation, so depending on tokio channels requires compiling all of tokio, even if I don't need anything from tokio besides channels. Having channels in their own crate could be a very nice compilation time win for users in my situation.

[Darksonn]

Tokio used to be split into many crates like that. We undid it because it causes significant maintenance burden. Also, even though tokio::sync can be used outside of Tokio, it still has an optimization that applies when used inside a Tokio runtime knowns as cooperative scheduling.

As for the compile time, Tokio has feature flags that let you disable things you don't need. By only enabling sync, the runtime does not get compiled.

[mxgrey]

Thanks for pointing out that the sync feature flag will let me avoid unnecessary compilation. That should work great for my use case.