Dave Bakker

BTW, if the answer is something along the lines of: _"without having to know what kind of output-stream it is, consumers should follow the check-write, write & flush recipe"_, then...

Maybe this can be merged with #76, as this non-blocking behavior is essentially the same as a timeout of `0`?

I've updated the definitions. Pretty much the entire text has changed so please check again (sorry). Noteworty changes: - There are now two dinstinct functions. - The future now returns...

After discussion in #73, I realized my interpretation of flush was not quite correct. I've removed the `flush-on-block` flag.

Appears to be a similar approach: https://github.com/bytecodealliance/jco/blob/7614126450b6cc0051d17f92ba41a126468580e7/packages/preview2-shim/lib/browser/io.js#L148-L153

@alexcrichton Do you agree with this approach? Notably: > Can we make it such that the splice implementation first reads into a per-stream stash and only then attempt to write...

> Do we have any use cases that need atomic behavior? If not, then we should at least document this behavior.

FYI, the preview1 component adapter always performs a blocking flush on each write regardless of non-blocking status. So those users are already good to go.

This is implemented in wasmtime as of https://github.com/bytecodealliance/wasmtime/pull/9381 behind the `-Scli-exit-with-code` flag

Feel free to use https://github.com/badeend/vscode-wit/blob/main/logo.png It might not be the most inspiring creation, but at least it stands out a bit: