On Thu, May 16, 2024 at 9:46 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > Alright, unless anyone has an objection or ideas for improvements, I'm > going to go ahead and back-patch this slightly tidied up version > everywhere.
Of course as soon as I wrote that I thought of a useful improvement myself: as far as I can tell, you only need to do the extra poll on the first wait for WL_SOCKET_READABLE for any given WaitEventSet. I don't think it's needed for later waits done by long-lived WaitEventSet objects, so we can track that with a flag. That avoids adding new overhead for regular backend socket waits after authentication, it's just in these code paths that do a bunch of WaitLatchOrSocket() calls that we need to consider FD_CLOSE events lost between the cracks. I also don't know if the condition should include "&& received == 0". It probably doesn't make much difference, but by leaving that off we don't have to wonder how peeking interacts with events, ie if it's a problem that we didn't do the "reset" step. Thinking about that, I realised that I should probably set reset = true in this new return path, just like the "normal" WL_SOCKET_READABLE notification path, just to be paranoid. (Programming computers you don't have requires extra paranoia.) Any chance you could test this version please Alexander?
v3-0001-Fix-FD_CLOSE-socket-event-hangs-on-Windows.patch
Description: Binary data
