-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fd_write only prints first element of the iovec #629
Comments
I haven't investigated this yet, but just a quick note that that's not necessarily a bug; Also, wasmtime can read .wat files directly, so you can skip the wat2wasm step :-). |
Oh, good point. Indeed, you are right, it reports Feel free to close this if there is nothing actionable here now. |
This is at least a QOI issue, because clearly it would be better to write the whole output when it isn't impractical to do so. This might be related to our use of Rust's |
Hmm, I think that writing our own wrapper for this shouldn't be too difficult (in fact, I think we already had some code that called the underlying OS APIs directly in the past). I'd hate to see the generality of our current solution across different hosts go though; i.e., Rust's |
I agree yeah that this is probably a bug in Rust's libstd not implementing In that sense I don't think this is a correctness bug, but Rust's libstd should work harder to consume all the input buffers regardless, and so this'd likely be best fixed by patching Rust's libstd implementation. |
This commit implements the `write_vectored` method of the `LineWriter` type. First discovered in bytecodealliance/wasmtime#629 the `write_vectored` method of `Stdout` bottoms out here but only ends up writing the first buffer due to the default implementation of `write_vectored`. Like `BufWriter`, however, `LineWriter` can have a non-default implementation of `write_vectored` which tries to preserve the vectored-ness as much as possible. Namely we can have a vectored write for everything before the newline and everything after the newline if all the stars align well. Also like `BufWriter`, though, special care is taken to ensure that whenever bytes are written we're sure to signal success since that represents a "commit" of writing bytes.
…, r=sfackler std: Implement `LineWriter::write_vectored` This commit implements the `write_vectored` method of the `LineWriter` type. First discovered in bytecodealliance/wasmtime#629 the `write_vectored` method of `Stdout` bottoms out here but only ends up writing the first buffer due to the default implementation of `write_vectored`. Like `BufWriter`, however, `LineWriter` can have a non-default implementation of `write_vectored` which tries to preserve the vectored-ness as much as possible. Namely we can have a vectored write for everything before the newline and everything after the newline if all the stars align well. Also like `BufWriter`, though, special care is taken to ensure that whenever bytes are written we're sure to signal success since that represents a "commit" of writing bytes.
This has been updated in rust-lang/rust at rust-lang/rust#67270 to print out everything by default, but in the meantime this still doesn't actually quite work naively at the console due to this block where @sunfishcode do you think it's worth trying to change this behavior? Given that it's all along this time been conforming to the function's contract, I'd be tempted to close this. |
Maybe hair-splitting here, but what happens if there is more than one buffer, but the first one is empty? Is it according to the function’s contract to only look at the first buffer (and thus always return “zero bytes written”)? (I guess https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-api.md#fd_write only says that its similar to |
This is admittedly a gray area, but my current understanding comes from text in POSIX discussing atomicity which says "It is a known attribute of terminals that this is not honored, and terminals are explicitly (and implicitly permanently) excepted". Since |
I've now submitted #781 which fixes this, adding |
Consider this Wasm module:
if I run this as
I get
not
It seems thta
fd_write
only takes the first element of the iovec.If I set the third argument to 0 it prints nothing (as it should).
The text was updated successfully, but these errors were encountered: