async-std
async-std copied to clipboard
async-rs
block_on doesn't return the output of a future on wasm
This caught me off guard today. It also causes #[async_std::test] to fail in cases where the test has a non-unit return type (like a result), since the macro wraps the testcase with block_on, which in wasm discards the return type due to this issue.
Conceptually, what is the reason that we couldn't implement this in WASM? If we can spawn tasks locally and get a join handle, what prevents us from doing something dumb like repeatedly polling the join handle in a busy loop?
what prevents us from doing something dumb like repeatedly polling the join handle in a busy loop?
I haven't tried tests on WASM in a while, so I'm not up to date with what the limitations are and how we should proceed to improve the current situation.
But spinning in a busy loop for unbounded durations in a browser environment is asking for trouble. Say the only future we're waiting on is a network request, and the network is slow. The browser may very well flag the tab as unresponsive before the request completes.
could have a spin / sleep combo so that it doesn't get killed by the browser? some kind of exponential backoff for polling up to a max? ( pragmatism beats not working because the signature is different )
pragmatism beats not working because the signature is different
This opens up a risk of potentially exhausting resources on target machines, especially since block_on is used at entry points and might spin for extended periods. Realistic outcomes include both tabs crashing, and operating systems grinding to a halt. Resource exhaustion errors are notoriously hard to debug since the system will often kill whatever's exhausing resources (or go into an unresponsive state) meaning you can't prod it.
Instead using something like localghost::main will provide a non-blocking async entrypoint for WASM programs targeting browsers. It can't return values to outside of WASM (yet), but using some channel APIs that can be mitigated.
FYI https://github.com/zesterer/pollster is a wasm compatible implementation of block_on that does return.
Isn't thread parking supported on WASM now thanks to atomics? This shouldn't be an issue anymore.
