On Tue Dec 20 09:31:09 2022 +0000, Hans Leidekker wrote:
"winhttp: Only read server reply in send_request() if the whole request is sent." would be a better title for this patch. It won't block this patch but I still think that the state machine is overly complex. I suspect that a model where we always queue but synchronize when the request is synchronous or when it is opportune would simplify this.
I am afraid we can't plainly queue and wait in WinHttpReceiveResponse(), it will currently block if queued from async callback as we have one thread processing requests at a time. Or do you mean something else?
As I recently discovered however such a behaviour is not the case on Windows. I can queue request from async callback and wait for event to be signaled by its completion notification; that will go to another thread and won't deadlock (unlike our winhttp currently). I have not yet encountered an app depending on that. Yet, even if implementing that (which might be not entirely trivial as I suspect some synchronisation should still exist) we would be moving implementation farther away from Windows. I don't know any app currently depending on the request to be completed not just synchronous but on the same thread, but I keep encountering more and more patterns of winhttp async usage across the games. Might be only a matter of time until some game will depend not only on request completing synchoronously but also Tls variables being the same between the requester and notification.
We also have a bit of validation missing across the functions (e. g., WinHttpWriteData) which I suppose will need the request state as well.
Yet quite possible there is still some way to straighten this up which I don't yet see...