Repository navigation
[wasi] Support zero-byte socket receives - #136394
Merged
Merged
Conversation
Unix implements a zero-byte receive as a 1-byte MSG_PEEK, which wasi-libc rejects with EOPNOTSUPP, so zero-byte receives failed on WASI. On WASI, poll the socket for input with a zero timeout instead. If the socket can't be polled (for example an unconnected TCP socket), issue a zero-length recv so the real error (ENOTCONN) is reported. Queued zero-byte receives re-run this check rather than completing on any poll event. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
lewing
marked this pull request as ready for review
October 23, 2026 22:44
Contributor
|
Tagging subscribers to this area: @karelz, @dotnet/ncl |
Contributor
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
This was referenced Oct 24, 2026
pavelsavara
approved these changes
Oct 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Unix, a zero-byte receive is implemented as a 1-byte
MSG_PEEK. wasi-libc rejectsMSG_PEEKwithEOPNOTSUPP, so every zero-byte receive fails on WASI. Callers such as HTTP/2 inSocketsHttpHandlerrely on zero-byte reads to wait for data.This was split out of #136234 at a reviewer's request.
Fix
On WASI, a zero-byte receive with no flags now does this instead:
POLLINwith a zero timeout, and completes only when the socket is readable.recvso the real error is reported. For example, wasi-libc returnsEOPNOTSUPPfor an unconnected TCP socket, and therecvreportsENOTCONNinstead.Non-WASI behavior is unchanged.
Not covered: a zero-byte
ReceiveFrom/ReceiveMessageFromthat passes an endpoint still takes theMSG_PEEKpath on WASI.Known caveat
After data has been drained, one zero-byte receive can complete early, because wasmtime keeps readiness set until a read would block. wasmtime treats this as by design (bytecodealliance/wasmtime#9667). The next real read then waits correctly.
Validation
SendReceive_*classes (Sync, SyncForceNonBlocking, Apm, Task, Eap, SpanSync, MemoryArrayTask, MemoryNativeTask). Total was 252 with 0 failed, and both new tests passed in every variant.Receive0Byte_NotConnected_Throwsruns on all platforms.Receive0Byte_Udp_CompletesWhenDatagramArrivesruns on Unix only, because on Windows a zero-byte receive consumes the datagram.SocketsHttpHandler/HTTP/2 isn't enabled on WASI in main, so the motivating HTTP/2 scenario is covered in [wasi] Enable SocketsHttpHandler and WebSockets #136234 rather than here.fgopt.cppfix from Fix build break #136388. That fix is not part of this PR.Related: #107981
Note
This PR was generated with GitHub Copilot.