On Mon, Jan 10, 2022 at 12:00 AM Alexander Lakhin <exclus...@gmail.com> wrote: > Going down through the call chain, I see that at the end of it > WaitForMultipleObjects() hangs while waiting for the primary connection > socket event. So it looks like the socket, that is closed by the > primary, can get into a state unsuitable for WaitForMultipleObjects().
I wonder if FD_CLOSE is edge-triggered, and it's already told us once. I think that's what these Python Twisted guys are saying: https://stackoverflow.com/questions/7598936/how-can-a-disconnected-tcp-socket-be-reliably-detected-using-msgwaitformultipleo > I tried to check the socket state with the WSAPoll() function and > discovered that it returns POLLHUP for the "problematic" socket. Good discovery. I guess if the above theory is right, there's a memory somewhere that makes this level-triggered as expected by users of poll().
