I think the missing piece is that `curl` never uses asynchronous or overlapped sends,
No, it is not missed. Yet maybe it is just me but I don't actually understand from this description how the suggested checks helps exactly and what curl does:
So the problem isn’t that sends happen slightly later than they should. It’s a fixed one-second delay for every \~64 KB burst, which matches the roughly 140 KB/s throughput users report. Under the current Wine behaviour there’s simply no wake-up path that can end that wait early. The discrepancy is in `select()`: on Windows, the pre-check reports the socket as writable whenever a `send()` would accept data, so `curl` never enters the wait in the first place.
I don't yet understand how that works on Windows vs Wine exactly. It can't be just pushing data in a tight loop infinitely, it should wait somewhere? Or does it end up on Windows somehow not sleeping on anything at all and just trying send in a tight loop? It is not clear yet to me where is that 1 sec timeoout. If you understand all that maybe it would be easier to write some few lines of [pseudo]code from which it would be clear how it is supposed to wait for send ready without sleeping for 1 sec but yet waiting for send somehow. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11272#note_144875