std.net: use send/recv for streams, support vectorized network io on windows #19751
+529
−402
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.
The primary goal of this change is to use
send
andrecv
for network streams, this also enables passing per-message flags likeMSG_NOSIGNAL
instead of installing a SIGPIPE handler.Introduces a mostly platform agnostic iovec as
std.net.iovec
andstd.net.iovec_const
. This provides a singular interface to vectorized network I/O on windows and posix.u32
for lengths and posix usingusize
. This requires any code currently usingusize
to@intCast
into the length field.Removes std.os.windows.ws2_32.WSARecvMsg, as it is not present in ws2_32.dll and must be fetched via WSAIoctl.
sendto
andrecvfrom
wrappers aroundWSASendTo
andWSARecvFrom
have been removed fromstd.os.windows
. These functions are already provided byws2_32
and are not needed.A os-agnostic IoVec struct (re #7699) would likely be more convienent to use, but I could not design an interface that both works well and is reasonable to interact with.
A potential problem this PR introduces is passing
WSABUF_const
toWSASendTo
andWSASend
is that this type doesn't actually exist in windows. Windows makes no guarantees that the buffers will not be modified.This enables the "general client/server API coverage" test on windows. The comment on the skip claims that the test was never passing, however during my tests the test passed 100% of the time.
Depends on #19768.