-
Notifications
You must be signed in to change notification settings - Fork 78
Open
Description
WASM targets don't support Async
and probably won't until WASI reaches a more stable point. However, since parking
is usable on WASM thanks to atomics, it may be desirable to use the Timer
implementation.
My suggestion is to add two new features: io
and timers
. They compose as such:
- With both features enabled (they are by default), the crate functions as normal.
- With
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
. - With both features disabled,
Reactor
no longer exists andblock_on
is just an alias to the ones infutures_lite
.
This would be a breaking change.
ibraheemdev, TennyZhuang and keller-mark
Metadata
Metadata
Assignees
Labels
No labels
Activity
taiki-e commentedon Sep 8, 2022
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.
notgull commentedon Sep 8, 2022
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.
notgull commentedon Dec 1, 2022
A few points of note I discovered while implementing this:
Instant::now()
is unimplemented for WASM, which means we'd have to useinstant
or something similar. However with the current API ofTimer
this means thatinstant
would be in the public API, unless we madeat
orinterval_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.notgull commentedon Feb 4, 2024
Not relevant for now
[-]Optionally disable timers or Asyncs on features[/-][+]Enable usage of timers on WASM[/+]