zoren added the bug label to Issue #7757.
zoren opened issue #7757:
Test Case
Steps to Reproduce
Run the attached binary. Observe only one line is written.
Expected Results
I expected two lines to be written to standard out.
❯ wasmer write2.wasm hello world HELLO WORLD
Actual Results
I only get one line written to standard out.
❯ wasmtime write2.wasm hello world
Versions and Environment
Wasmtime version or commit: wasmtime-cli 16.0.0 (6613acd1e 2023-12-20)
Operating system: macOS 14.2.1
Architecture: M1
Extra Info
Anything else you'd like to add?
It seems the implementation of
fd_write
will only print the first non-empty buffer. https://github.com/bytecodealliance/wasmtime/blob/7690c500228ae005fc70ee3b6297bb4b403686d5/crates/wasi-preview1-component-adapter/src/lib.rs#L1422This I believe is unlike
writev
in POSIX. But I have not tested this out.
zoren edited issue #7757:
Test Case
Steps to Reproduce
Run the attached binary. Observe only one line is written. The binary puts two elements in an io vector but only one is printed.
Expected Results
I expected two lines to be written to standard out.
❯ wasmer write2.wasm hello world HELLO WORLD
Actual Results
I only get one line written to standard out.
❯ wasmtime write2.wasm hello world
Versions and Environment
Wasmtime version or commit: wasmtime-cli 16.0.0 (6613acd1e 2023-12-20)
Operating system: macOS 14.2.1
Architecture: M1
Extra Info
Anything else you'd like to add?
It seems the implementation of
fd_write
will only print the first non-empty buffer. https://github.com/bytecodealliance/wasmtime/blob/7690c500228ae005fc70ee3b6297bb4b403686d5/crates/wasi-preview1-component-adapter/src/lib.rs#L1422This I believe is unlike
writev
in POSIX. But I have not tested this out.
bjorn3 commented on issue #7757:
Trying to process all buffers in a loop would violate the atomicity guarantee POSIX gives for writev in the presence of other programs writing to the same file.
The data transfers performed by readv() and writev() are atomic: the data written by writev() is written as a single block that is not intermingled with output from writes in
other processes; analogously, readv() is guaranteed to read a contiguous block of data from the file, regardless of read operations performed in other threads or processes that
have file descriptors referring to the same open file description (see open(2))The current behavior is allowed for writev:
Note that it is not an error for a successful call to transfer fewer bytes than requested (see read(2) and write(2)).
It is not the fastest though of course, but wasi-preview2 doesn't support vectorized reads and writes at all from what I can tell, so the current behavior shouldn't be much of a difference compared to doing the loop inside the fd_write impl.
The old wasi-preview1 implementation which isn't layered on top of wasi-preview2 as compat layer does support vectorized reads and writes afaik.
pchickey closed issue #7757:
Test Case
Steps to Reproduce
Run the attached binary. Observe only one line is written. The binary puts two elements in an io vector but only one is printed.
Expected Results
I expected two lines to be written to standard out.
❯ wasmer write2.wasm hello world HELLO WORLD
Actual Results
I only get one line written to standard out.
❯ wasmtime write2.wasm hello world
Versions and Environment
Wasmtime version or commit: wasmtime-cli 16.0.0 (6613acd1e 2023-12-20)
Operating system: macOS 14.2.1
Architecture: M1
Extra Info
Anything else you'd like to add?
It seems the implementation of
fd_write
will only print the first non-empty buffer. https://github.com/bytecodealliance/wasmtime/blob/7690c500228ae005fc70ee3b6297bb4b403686d5/crates/wasi-preview1-component-adapter/src/lib.rs#L1422This I believe is unlike
writev
in POSIX. But I have not tested this out.
pchickey commented on issue #7757:
As @bjorn3 has described, this behavior is working as intended - The caller of fd_write need to take into account that it may not consume the entire output and it may need to be called again. I'm going to close this issue, but you can re-open if that is not what you are observing.
Last updated: Nov 22 2024 at 17:03 UTC