-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
std.net: use send/recv for streams, support vectorized network io on windows #19751
base: master
Are you sure you want to change the base?
Conversation
7e204ba
to
74a9a6a
Compare
5dae7fd
to
264bef2
Compare
For what it's worth, the |
I decided to avoid writing definitions for msghdr and mmsghdr because nothing in std.net needs them (right now, they are necessary for sending flags with iovecs, but that can be easily hidden). I'm not sure a cross platform definition of msghdr is even necessary for TCP because WSASend/WSARecv already do vectorized IO and don't enable any extra features. And outside of Windows, |
104d85c
to
6346063
Compare
39db871
to
73f9d7e
Compare
73f9d7e
to
3c5bd18
Compare
bed57d5
to
1524409
Compare
No idea why
|
7c461e7
to
79368f7
Compare
Macos uses the BSD definition of msghdr All linux architectures share a single msghdr definition. Many architectures had manually inserted padding fields that were endian specific and some had fields with different integers. This unifies all architectures to use a single correct msghdr definition.
The primary goal of this change is to use `send` and `recv` for network streams, this also enables passing per-message flags like `MSG_NOSIGNAL` instead of installing a SIGPIPE handler. - Alongside using recv and send, windows now uses WSARecvFrom and WSASendTo for readv and writev. This enables vectorized network I/O on windows. Introduces a mostly platform agnostic iovec as `std.net.IoSlice` and `std.net.IoSliceConst`. This provides a singular interface to vectorized network I/O on windows and posix. - The only problem this introduces is windows using `u32` for lengths and posix using `usize`. So windows is limited to 4GB slices while posix is not. Removes std.os.windows.ws2_32.WSARecvMsg, as it is not present in ws2_32.dll and must be fetched via WSAIoctl. - The `sendto` and `recvfrom` wrappers around `WSASendTo` and `WSARecvFrom` have been removed from `std.os.windows`. These functions are already provided by `ws2_32` and are not needed. 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. std.net: adjust send/recv error sets to match documentation std.posix: clean up send and recv error sets, add recvmsg std.net.Stream readv and writev are now implemented with sendmsg and recvmsg. This primarily removes strictly file-related errors from the error sets and removes a layer of indirection in the kernel. grafted Add ECONNREFUSED to sendto
79368f7
to
91e14f5
Compare
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, linux usingusize
and BSDs using i32. 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.This partially implements an os-agnostic iovec, but only with respect to sockets (re #7699).
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.