Force-pushed a reworked version; the description is updated to match. The original version could deadlock. TIOCOUTQ reports queued payload bytes, but the kernel blocks a send on truesize accounting (sk_wmem_queued against sk_sndbuf), so near the blocking boundary it could report a socket writable when a send would in fact block. The full ws2_32:sock unit reproduces this deterministically here: test_select walks a blocking send into a full socket the old predicate had just called writable, and it never returns. That was present in the version you were reviewing. Chasing it exposed the same divergence a second time, inside send_socket(), which the description covers. The new version uses one predicate at both sites, taken from the kernel rather than approximated. @zfigura, on your point about waking a wait that is already blocked without kernel changes: I built the FD_WRITE re-arm and tested it against real Windows before submitting anything. Windows does not re-arm FD_WRITE when a poll observes the socket as not writable; the wait times out exactly as it does on Wine. Only a failed send re-arms. So the re-arm is not the answer, and the series pins that behaviour in a test instead. @gofman, your remark about Windows never short-writing shaped the test design. The fill loops stop at the first WSAEWOULDBLOCK and skip rather than assert when the state cannot be reached, which is what keeps them meaningful on the TestBot Windows images. TestBot for the new series, no new failures across XP through Windows 11 and the Wine VMs: https://testbot.winehq.org/JobDetails.pl?Key=163922 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11272#note_148071