Make splice atomic

[badeend]

Partly a PR, partly a question: what is supposed to happen with the already read data in case the write within splice fails?

Currently, wasmtime throws the data away.

Can we make it such that the splice implementation first reads into a per-stream stash and only then attempt to write it into the destination output stream? Future reads then first check if there is any data in its local stash, before calling the backing implementation.

I think this is in line with Linux' splice and sendfile

[pchickey]

Yes, we should follow the lead of splice(2) and not throw away read bytes if a write fails. I was lazy about doing that correctly in wasmtime's implementation, but the behavior as it exists today is not desirable.

@guybedford what is the jco behavior for splice?

[badeend]

Appears to be a similar approach:

https://github.com/bytecodealliance/jco/blob/7614126450b6cc0051d17f92ba41a126468580e7/packages/preview2-shim/lib/browser/io.js#L148-L153

[badeend]

@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 it into the destination output stream? Future reads then first check if there is any data in its local stash, before calling the backing implementation.

[alexcrichton]

I think that's a good approach yeah, and I would agree that it'd be surprising to lose data otherwise via a splice, so sounds like a good change to me!

[sunfishcode]

Do we have any use cases that need atomic behavior?

One of the original motivations for adding splice was for implementing std::io::copy in Rust, and Rust's API doesn't guarantee atomic behavior.

When we added splice, the expected use cases were where the only thing one is going to do with the data is write it to the output, so if the write fails, the caller isn't going to try to read the data again and do something else with it. I'm hesitant here to add more burden on implementers if we don't have a usecase that needs it.

[badeend]

Do we have any use cases that need atomic behavior?

If not, then we should at least document this behavior.

[ricochet]

Thank you for contributing to WASI!

As part of our proposal management process, we decided to consolidate all phase 3 proposals into a single monorepo at WebAssembly/wasi to better manage the proposals that have reached phase 3.

We have completed migrating all phase 3 proposals to WebAssembly/wasi including their issues, but PRs need to be re-opened in the new repository. This is a GitHub limitation and we're sorry for the inconvenience. Please re-open this PR on WebAssembly/wasi. Thank you!