I'm starting work on a project I'm calling WASI Preview2, which I hope will become a major update to WASI.
The biggest change is to move from witx to wit, and use wit-bindgen, and to build up wasi-libc/wasi-sdk/rust wasi support on top of that.
The meeting info for the WASI Preview2 presentation is here.
Will there be a ppt or slide deck?
The slides aren't quite finished yet, but I definitely do plan to add the slides to the meeting notes.
PR to add the slides to the meeting notes is here: https://github.com/WebAssembly/meetings/pull/1066
I think a readyness based stream api makes more sense from a determinism, safety and predictability based perspective. The api you suggested allows writing at any point between a read/write and a wait. This is less deterministic as you have to know the exact instruction at whicj the write happened to replay it. It makes it easier to accidentally deallocate a buffer which is still registered as read/write target and it makes it harder for someone trying to read the code to know if some data doesn't get overwritten by a read operation.
You're correct, the API presented there has the data arriving in the buffer at nondeterministic times. And the user has to keep it allocated and immobile while a read or write is in flight.
My understanding is that the main idea here is that the low-level stream details here would be hidden in a source language's async runtime.
I should mention that this stream design is part of the component model, and my presentation here is just showing what it would look like in the core-wasm ABI implemented by engines.
How would for example tokio be able to abstract over it without forcing a copy?
I myself don't know the plan for that right now. But I do know that this design is being developed in close cooperation with people who have deep Rust async experience.
Last updated: Nov 22 2024 at 16:03 UTC