Hi Sergei, Thanks for the report and fix.
> Hello, while investigating the cause of the infinite hang in WGET2-MINGW, I > discovered that the gnulib implementation of the poll() function does not > set the POLLIN event flag in revents (but only the POLLHUP flag) after the > connection is hang up (see https://gitlab.com/gnuwget/wget2/-/issues/715). > > The reasons why poll() should also set the POLLIN event flag in revents > (not only the POLLHUP flag) in this situation are as follows: > > (1) The semantics of POLLIN mean that reading the socket can be done > without blocking (not that there is data in the socket buffer). Yep, you are right. Many years ago, when getting familiar with the select(2) API, that was also my first misunderstanding. > (2) There are already established patterns of using this function, when the > application first waits for the POLLIN event, and then, based on the result > of the read operation, determines whether the connection was closed > correctly or whether the connection was broken. Interesting. Didn't know. > (3) The Linux native poll() implementation sets the POLLIN event flag > (along with the POLLHUP flag) in revents under the same circumstances . Yep, the code at https://elixir.bootlin.com/linux/v6.18.6/source/net/ipv4/tcp.c#L588 seems to confirm what you say. > In the attached patch, I propose a fix for the poll() function. Thanks for the patch, both for the Windows and the Unix parts. I'm applying it, with the following ChangeLog entry: 2026-02-10 Sergei Litvin <[email protected]> poll: When setting POLLHUP in revents, set also POLLIN and POLLRDNORM. This fixes a hang of wget2 on Windows <https://gitlab.com/gnuwget/wget2/-/issues/715>. * lib/poll.c (windows_compute_revents_socket): Set POLLIN and POLLRDNORM whenever lNetworkEvents has one of the bits FD_READ, FD_ACCEPT, FD_CLOSE set. (compute_revents): Set POLLIN and POLLRDNORM whenever fd is set in rfds[].
