On Tue Dec 20 15:18:19 2022 +0000, Paul Gofman wrote:
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...
Not directly related, but now when stomping on those requests completed with WinHttpWriteData() I got curious how that is supposed to work with recursive requests and figured we are not handling it right (tested with redirect). We will currently send recursed request without body if it is not provided in optional data. Windows in this case returns ERROR_WINHTTP_RESEND_REQUEST and then resending the request and resupplying the data with WinHttpWriteData() lets it complete correctly. I have a patch for that but that is pre-existing issue and not a regression, so probably for after code freeze.