Hi all, Before I open a merge request, I’d like feedback on the approach, as it has a portability angle I’m unsure about. Question up front: the fix relies on TIOCOUTQ to query the amount of unsent data in a socket’s send buffer. That is Linux-specific. Is gating it on #ifdef TIOCOUTQ (leaving current behaviour unchanged elsewhere) acceptable, or would you prefer a different mechanism, or a different layer than poll_socket()? I’d rather hear that now than in review. On Windows, select() reports a connected stream socket writable whenever a send() would still accept data into the send buffer. Wine derives writability from the host poll(); on Linux POLLOUT is only set once the send queue has drained below roughly 2/3 of SO_SNDBUF. So while the buffer is between ~2/3 full and full, Windows says “writable” but Wine says “not writable” even though send() still succeeds. The common application pattern is a non-blocking select() writability check before waiting on an FD_WRITE event. libcurl’s multi loop does exactly this. Under Wine, an app-limited sender (sends keep succeeding, never hitting WSAEWOULDBLOCK) sees “not writable” while it still has room, and since FD_WRITE is edge-triggered and not re-recorded until a send fails, it waits out its full poll timeout (typically 1s) between bursts. Single-stream uploads end up throttled to ~140 KB/s. I found this with a libcurl-based backup client whose uploads could not finish within their timeout under Wine. Proposed fix: In poll_socket(), when the immediate poll() does not report POLLOUT for a connected stream socket that still has send-buffer room (TIOCOUTQ < SO_SNDBUF), report it writable. One small block, #ifdef TIOCOUTQ. Conformance: I have a ws2_32:sock test (the invariant: select() reports writable exactly while send() accepts data). On the same test binary: * real Windows pass (0 violations) * Wine, unpatched fail (~230 of ~660 sends report not-writable yet send ok) * Wine, patched pass (0 violations) I’ll submit the test as a todo_wine commit ahead of the fix. One thing I tried and dropped: I first also changed FD_WRITE to re-arm on every send. A conformance test on real Windows showed Windows does NOT re-arm FD_WRITE after a successful send (only after WSAEWOULDBLOCK, matching MSDN), so that change would have diverged from Windows. The writability fix alone is sufficient and is the Windows-conforming part. For background, curl’s issue #6146 (https://github.com/curl/curl/issues/6146) documents this same select/FD_WRITE behaviour on Windows; curl’s workaround is the select()-before-wait pre-check in commit a69d1a4 (PR #5634, “multi: implement wait using winsock events”). That pre-check is exactly the path this fix unblocks under Wine. Bug: https://bugs.winehq.org/show_bug.cgi?id=59893 Happy to adjust the mechanism based on what you’d prefer here. Thanks, Martyn Forryan