Open notgull opened 2 years ago
I'm not sure if we need to introduce such a breaking change to support WASM. Currently, async-io fails to compile on WASM anyway, so I think just disabling some APIs in WASM is not a problem.
That's probably the best way of going about this. I'll rearrange the PR I wrote to use OS flags instead of feature flags.
A few points of note I discovered while implementing this:
Instant::now()
is unimplemented for WASM, which means we'd have to use instant
or something similar. However with the current API of Timer
this means that instant
would be in the public API, unless we made at
or interval_at
unavailable for WASM.-Ctarget-feature=+atomics
flag needs to be enabled. However, trying to rebuild libstd with that gives me an ICE. I'll investigate more before I file a Rust bug.Not relevant for now
WASM targets don't support
Async
and probably won't until WASI reaches a more stable point. However, sinceparking
is usable on WASM thanks to atomics, it may be desirable to use theTimer
implementation.My suggestion is to add two new features:
io
andtimers
. They compose as such:io
disabled buttimers
enabled, theReactor
retains its timer processing capabilities but instead of calling topolling
, it callsparking
(which works with WASM) with the timeout resulting fromprocess_timer_ops
.Reactor
no longer exists andblock_on
is just an alias to the ones infutures_lite
.This would be a breaking change.