I think at very least the added condition is missing async_queue_has_waiting_asyncs( &sock-\>write_q ) check.
That's handled by sock_dispatch_asyncs(), which clears POLLOUT etc when satisfying a waiting async.
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).
I think this is an orthogonal problem?
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.
That occurred to me, but I'm not sure there's a way to, without kernel modification. Maybe that's warranted here? Depending on the loop there still might be throttling. 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).
I don't think that's right or a good idea. Windows does have a buffer limit, and letting writes queue forever is probably a bad idea. ``` + /* Linux withholds POLLOUT until the send queue has drained well below + * SO_SNDBUF, while Windows reports a stream socket writable whenever + * send() can still accept data. If there is any send-buffer space + * left, report writability here to match Windows semantics. */ ``` Do we know whether this behaviour is specific to Linux? Should we specifically guard for Linux, not just TIOCOUTQ? ``` + sock->type == WS_SOCK_STREAM && sock->state == SOCK_CONNECTED && !sock->wr_shutdown && ``` SOCK_CONNECTED should imply SOCK_STREAM. But what about UDP sockets? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11272#note_144443