-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASI support? #102
Comments
There's this branch, but I'm not sure if @yoshuawuyts is actively working on it. We could probably support WASI with the same caveats the |
Oh, so I'm currently working together with Sunfish to land the We probably shouldn't do anything for Hope that helps! |
Sounds good, thanks for clarifying! It's probably better to wait for |
Thanks for the update! That makes a lot of sense :) As far as the lack of WASI threads goes, it at least feels like it should be theoretically possible to have some kind of |
This commit adds support for async-io on wasm32-unknown-unknown. Not all features of async-io can be ported to WASM; for instance: - Async<T> can't be ported over as WASM doesn't really have a reactor. WASI could eventually be supported here, but that is dependent on smol-rs/polling#102 - block_on() can't be ported over, as blocking isn't allowed on the web. The only thing left is Timer, which can be implemented using setTimeout and setInterval. So that's what's been done: when the WASM target family is enabled, Async<T> and block_on() will be disabled and Timer will switch to an implementation that uses web timeouts. This is not a breaking change, as this crate previously failed to compile on web platforms anyways. This functionality currently does not support Node.js. Signed-off-by: John Nunley <[email protected]>
|
(It is likely to be reverted once, though: rust-lang/rust#120434) |
A new version of the edit: I think this roughly looks right. I'm currently working on an HTTP client crate for a project, and so I need to have some way to convert from the low-level WASI |
@yoshuawuyts Great! The only thing missing is a way to wake up the |
Yeah that's right - though more specifically: WASI 0.2 doesn't have them. WASI 0.1 has something experimentally, but that's not the right thing. For 0.2 we're working on that now as a canonical built-in to WASI (rather than as an extension to Wasm core directly). The progress on that is looking good, and I think we can expect it to land probably around Q3 of this year? Experimentally probably even sooner? Anyway, yeah, for now that's not a thing we need to be able to do. |
Finished writing a wasi native async runtime, and wrote down step by step instructions for how this all works here: https://blog.yoshuawuyts.com/building-an-async-runtime-for-wasi/. If someone wants to integrate this into |
Mio has limited support for the
wasm32-wasi
target and I think it should therefore be possible to implement support here too, using WASI'spoll_oneoff
interface. This could be useful to allow for async TcpStreams and similar on wasm32-wasi rust binaries usingasync-io
The text was updated successfully, but these errors were encountered: