On Mon Aug 10 15:43:55 2026 +0000, Elizabeth Figura wrote:
I'm sorry, I'm having trouble reading through all of this. If you used AI to write or help write it, please don't; it invariably makes things harder to read (and be aware that using AI to write or help write patches themselves is not allowed for Wine). Otherwise can you please find a way to respond more succinctly? As far as I'm aware the main question is if there's any approach submitted or proposed which actually helps libcurl; if so we just need an explanation of what the call structure looks like such that the POLLOUT problem doesn't occur; if not we can look into putting something in the kernel, or maybe faking SNDBUF values. Apologies; I've been known for excess verbosity since school. I like to try and ensure I've covered everything possible, especially with a complicated or technical issue, but of course it runs the risk of turning into word soup.
Let me try again to answer your question with brevity: yes, the submitted patch. curl is the case it was written for. curl's loop, one iteration per burst: ``` if (select(writefds) says writable) send(~64K, non-blocking) /* succeeds, produce next chunk, loop */ else WSAWaitForMultipleEvents(FD_WRITE, 1000ms) ``` FD_WRITE only arms after a send fails with WSAEWOULDBLOCK. curl is application-limited and never fills the buffer, so no send ever fails, so the event is never armed. On stock Wine select() reports not-writable while the queue sits above Linux's POLLOUT threshold, curl takes the else branch into a wait nothing can signal, and burns the full second. One burst per second is the \~140 KB/s. With select() reporting writable whenever a send would be accepted, curl stays on the send path and only reaches that wait after send() returns WSAEWOULDBLOCK, which is the only time it can wake promptly. Measured: \~1 Mbit/s to \~79 Mbit/s on a 110 Mbit/s uplink, and the conformance test goes from \~230 violations in \~660 sends to zero. What it does not fix is a select() already blocked when space frees later. I conceded that to Paul and I still think it cannot be closed from the poll answer, so that gap is where a kernel change would be needed. Faking SNDBUF would not help this case. The stall is the POLLOUT threshold, not the buffer size. One thing to settle between you; Paul's objections to this approach stand and I had conceded them, and offered to build the write-queue alternative instead. You have since said that alternative does not fix the discrepancy, because sending from the queue is still throttled by POLLOUT. So the choice is this patch, Linux-specific and with the already-waiting gap, or the kernel route. I am happy to build whichever you both choose. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11272#note_148550