Wasmtime GitHub notifications bot (Nov 23 2024 at 08:16): Wasmtime GitHub notifications bot (Nov 23 2024 at 08:16):Heap-Hop opened issue #9667:
Returning
0forstd::io::ErrorKind::WouldBlockcauses downstream to interpret it as a closed stream, see:
https://github.com/yoshuawuyts/wstd/issues/25#issuecomment-2493294087.
https://github.com/yoshuawuyts/wstd/blob/5ce367add5e7bcb569b6487453cb9ba94468dc99/src/io/copy.rs#L12This is also found in:
https://github.com/bytecodealliance/wasmtime/blob/67674881db5fbdbba8594feb52655aaa351a5f77/crates/test-programs/src/bin/preview2_tcp_streams.rs#L17-L22Given that the
witfiles already include manywould-blockerrors, would it make sense to extendstream-errorto include aWouldBlock?
Wasmtime GitHub notifications bot (Nov 23 2024 at 08:19):Heap-Hop edited issue #9667:
Returning
0forstd::io::ErrorKind::WouldBlockcauses downstream to interpret it as a closed stream, see:
https://github.com/yoshuawuyts/wstd/issues/25#issuecomment-2493294087.
https://github.com/yoshuawuyts/wstd/blob/5ce367add5e7bcb569b6487453cb9ba94468dc99/src/io/copy.rs#L12This is also found in:
https://github.com/bytecodealliance/wasmtime/blob/67674881db5fbdbba8594feb52655aaa351a5f77/crates/test-programs/src/bin/preview2_tcp_streams.rs#L17-L22Given that the
witfiles already include manywould-blockerrors, would it make sense to extendstream-errorto include awould-block?
Wasmtime GitHub notifications bot (Nov 24 2024 at 20:09):pchickey commented on issue #9667:
Wasi streams operations are nonblocking, unless they have
blocking_in their name, so read should always return an empty list instead of blocking. Theblocking_functions are equivalent to waiting for readiness on the stream's pollable, and then calling the nonblocking variant.
Wasmtime GitHub notifications bot (Nov 24 2024 at 20:10):pchickey edited a comment on issue #9667:
WASI streams operations are nonblocking, unless they have
blocking_in their name, so read should always return an empty list instead of blocking. Theblocking_functions are equivalent to waiting for readiness on the stream's pollable, and then calling the nonblocking variant.This is a significant departure from POSIX, which uses the file's mode to make the read and write syscalls blocking or nonblocking. So, while it makes sense for POSIX to use an error to indicate when a nonblocking socket would block, it doesn't make sense for WASI to follow that same convention.
Wasmtime GitHub notifications bot (Nov 24 2024 at 20:59):bjorn3 commented on issue #9667:
How can you distinguish in WASI between an EOF stream (no data will be returned in the future because the connection was closed or the end of the file is reached) and a stream where you have to wait until the stream is ready before you can read more data? The distinction is very important for
std::io::copy/tokio::io::copywhich needs to continue reading until EOF and only returns when EOF is reached.
Wasmtime GitHub notifications bot (Nov 24 2024 at 21:00):pchickey commented on issue #9667:
When the stream is EOF, it retusn Err(StreamError::Closed) as seen in the above snippet line 21.
Wasmtime GitHub notifications bot (Nov 24 2024 at 21:01):pchickey edited a comment on issue #9667:
When the stream is EOF, it returns Err(StreamError::Closed) as seen in the above snippet line 21. Maybe this isn't so much an "Error" as the "Err" constructor indicates, but the alternative was returning a custom enum there of Ok/Closed/Error, which we rejected on fairly arbitrary stylistic grounds.
Wasmtime GitHub notifications bot (Nov 25 2024 at 03:36):Heap-Hop commented on issue #9667:
Thanks for your kind explanation!
The pollable given by
subscribewill be ready whenmore bytesare available.I think it would be helpful to update the doc to explicitly note this situation for users.
Wasmtime GitHub notifications bot (Nov 25 2024 at 03:58):Heap-Hop commented on issue #9667:
Additionally, there's a potential bug in
HostInputStream::blocking_read(also affectsblocking_skip).
The doc states:it blocks until at least one byte can be read.The
ready()is implemented usingreadablefrom Tokio:However,
readablein Tokio does not block whenio::ErrorKind::WouldBlock.
Wasmtime GitHub notifications bot (Nov 25 2024 at 04:03):Heap-Hop edited a comment on issue #9667:
For the same reason, there's a potential bug in
HostInputStream::blocking_read(also affectsblocking_skip).
The doc states:it blocks until at least one byte can be read.The
ready()is implemented usingreadablefrom Tokio:However,
readablein Tokio does not block whenio::ErrorKind::WouldBlock.
Wasmtime GitHub notifications bot (Nov 25 2024 at 04:04):Heap-Hop edited a comment on issue #9667:
WASI streams operations are nonblocking, unless they have blocking_ in their name
For the same reason, there's a potential bug in
HostInputStream::blocking_read(also affectsblocking_skip).
The doc states:it blocks until at least one byte can be read.The
ready()is implemented usingreadablefrom Tokio:However,
readablein Tokio does not block whenio::ErrorKind::WouldBlock.
Wasmtime GitHub notifications bot (Nov 25 2024 at 04:05):Heap-Hop edited a comment on issue #9667:
WASI streams operations are nonblocking, unless they have blocking_ in their name
For the same reason, there's a potential bug in
HostInputStream::blocking_read(also affectsblocking_skip).
The doc states:it blocks until at least one byte can be read.The
ready()is implemented usingreadablefrom Tokio:However,
readablein Tokio does not await whenio::ErrorKind::WouldBlock.
Wasmtime GitHub notifications bot (Nov 25 2024 at 05:48):Heap-Hop commented on issue #9667:
Maybe all we really need is to ensure that every
ready()in WASI behaves as the explicit "ready" it's supposed to be.
Last updated: Dec 23 2024 at 12:05 UTC