g_poll() implementation on Windows stall when more than MAXIMUM_WAIT_OBJECTS FDs have passed
When I pass more than MAXIMUM_WAIT_OBJECTS
GPollFD
to g_poll
with timeout_ms
more than zero and no G_WIN32_MSG_HANDLE
special value in the FD set, the implementation is blocked for timeout_ms
time in line ready = WaitForMultipleObjects (nthreads, thread_handles, timeout > 0, timeout);
regardless the signaled states of the given FDs.
The comment /* Wait for at least one thread to return */
suggest that the third parameter of WaitForMultipleObjects
should be FALSE
to return when one of the thread just finished.
I don't know if the parameter timeout > 0
is intentional or I've just overlooked something, but I've created a workaround to move the thread stopping event code into the thread main code, to trigger an exit in other threads when the first signaled thread just about to return.
This issue relates to #1071 (closed).
Version: >= 2.59.1
OS: Windows 10 (10.0.18363.778)