Wasmtime GitHub notifications bot (Mar 09 2024 at 00:30): Wasmtime GitHub notifications bot (Mar 09 2024 at 00:30):ospencer opened PR #8072 from ospencer:oscar/fix-fd-write-iovs to bytecodealliance:main:
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
I noticed that the implementation offd_writein the preview1 adapter only writes the first iov in the list passed. This change writes all of them. I'm happy to add a test for this, though I couldn't find any tests for the adapter. I tested this locally via wasm-tools.
Wasmtime GitHub notifications bot (Mar 09 2024 at 00:30):ospencer requested alexcrichton for a review on PR #8072.
Wasmtime GitHub notifications bot (Mar 09 2024 at 00:30):ospencer requested wasmtime-core-reviewers for a review on PR #8072.
Wasmtime GitHub notifications bot (Mar 09 2024 at 14:18):Writing in a loop is incompatible with POSIX. POSIX mandates that each writev is an atomic operation. While it may only write the first n bytes, it has to write all n bytes at once without the possibility of any other write getting interleaved with it. If you want to write everything, you did have to copy all buffers into one large buffer and then write this large buffer, which may actually be slower than both the status quo and your PR. See also https://github.com/bytecodealliance/wasmtime/issues/8037#issuecomment-1973512565
Wasmtime GitHub notifications bot (Mar 11 2024 at 14:22):alexcrichton commented on PR #8072:
To add another case I would be worried about in addition to what @bjorn3 already mentioned: in the PR as-is if you have 4 buffers and successfully write the first two but then fail writing the third then the fact that the first two were successfully written is lost. At that point you've got a number of successfully written bytes plus an error and it's not clear which should be returned since only one can be returned.
Wasmtime GitHub notifications bot (Mar 16 2024 at 14:23):ospencer commented on PR #8072:
That makes sense. It looks like some implementations of
readv/writevdo allocate a temporary large buffer in the case that the number of provided iovs exceeds the limit of the system, so that probably makes sense here too.I agree that the current implementation we have of
fd_writeis technically correct, but I think the (totally allowable) behavior change from older preview1 versions of wasmtime is a little surprising to less resilient code, shown by the couple of issues/PRs opened about this.I attempted to implement this so we could at least test it out/consider this approach, but I forgot that the adapter can't really use
Vecs because of the panics. I'm not quite a seasoned-enough Rustacean to know how to do this without vecs in safe Rust, but if someone could give me a pointer that'd be much appreciated.
Wasmtime GitHub notifications bot (Mar 18 2024 at 14:52):alexcrichton commented on PR #8072:
I agree it's unfortunate that this is causing issues, but IMO our hands are unfortunately tied here to the point that there's not much we can do. I think there's one thing we can do, which is to have a statically allocated or somewhere slice of bytes which the adapter copies into and then calls out to perform a single write. That would respect the semantics desired for languages and such here, at the cost of copying data. It's not clear to me when the copy is worth it vs when not, so I'm not sure how to best make such a decision.
The adapter has various bits and pieces of scratch space in its
Stateand we can put a fixed-size buffer in there for copying if necessary.
Last updated: Oct 23 2024 at 20:03 UTC