Not sure I have a final suggestion at once, that could possibly use a bit of exploration (or a bit of more info on possibilities if some exploration has already been done). Does libcurl sender use synchronous or asynchronous socket writes? I think at very least the added condition is missing async_queue_has_waiting_asyncs( &sock->write_q ) check. But my initial thoughts that maybe we can consider a different way. Mind the following facts: 1. Windows never does short writes (regardless of the attempt size attempts, even if it is GBs, and regardless of SO_SNDBUG). We have partial support for that, see ntdll.dll/unix/sock.c:sock_send() (after "If we had a short write..." comment. IIRC we stomped upon the fact that sync sends also behave the same on Windows and that should probably be tested and implemented (that should likely be as easy as altering the condition after the said comment). 2. The suggested implementation will only satisfy select() when it is called when there is some free space in buffer but if it was already waiting and some space has been freed the select() won't be woken. Probably not a blocker per se, but maybe we can do better. In the view of 1, I am thinking that maybe instead of trying to tweak around Linux native buffer sizes and logic we can extend a bit the logic of our big buffer writeback (only for stream sockets), like: - always allow sending if there is no pending async writes (now we will allow only if partial write happened); - give up on Unix socket write polling entirely and satisfy WINAPI select / poll based on the absence of queued writes (of course we should also signal already waiting select once async write queue is empty). @zfigura any thoughts on that? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11272#note_144439