Skip to content

fix(windows): map WSAEWOULDBLOCK to wouldBlock for recv/send/recvmsg/sendmsg/writev - #3705

Open
wasim-builds wants to merge 1 commit into
apple:mainfrom
wasim-builds:fix/issue-3702-wsaewouldblock
Open

fix(windows): map WSAEWOULDBLOCK to wouldBlock for recv/send/recvmsg/sendmsg/writev#3705
wasim-builds wants to merge 1 commit into
apple:mainfrom
wasim-builds:fix/issue-3702-wsaewouldblock

Conversation

@wasim-builds

Copy link
Copy Markdown
Contributor

Fixes #3702 and #3697.

The Windows data-path wrappers for recv, send, recvmsg, sendmsg, and writev threw IOError for every SOCKET_ERROR, including WSAEWOULDBLOCK. This caused non-blocking socket backpressure to become a fatal channel error instead of resuming when the socket became readable/writable.

The accept and connect wrappers already handled WSAEWOULDBLOCK correctly (returning nil and false respectively). This applies the same pattern to the remaining data-path operations.

…sendmsg/writev

Fixes apple#3702: Windows data path treats WSAEWOULDBLOCK as fatal for recv, send, and writev.
Fixes apple#3697: WSASend error in bi-directional stream tests caused by the same missing wouldBlock mapping.

The accept and connect wrappers already returned nil/false on WSAEWOULDBLOCK.
This applies the same backpressure handling to the remaining data-path operations
so non-blocking Windows sockets resume correctly instead of closing the channel.
@wasim-builds
wasim-builds force-pushed the fix/issue-3702-wsaewouldblock branch from 54452ae to c6a8d18 Compare August 21, 2026 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows data path treats WSAEWOULDBLOCK as fatal (recv/send/writev)

1 participant