on windows 11 (but I think all windows version that use wepoll.c) I found a bad behavior if the internal wepoll request do not return one of EPOLLIN, EPOLLOUT, or EPOLLERR
because in PollSet we check that return code in this code

if (_events[i].events & EPOLLIN)
				result[it->second.first] |= PollSet::POLL_READ;
if (_events[i].events & EPOLLOUT)
				result[it->second.first] |= PollSet::POLL_WRITE;
if (_events[i].events & EPOLLERR)
				result[it->second.first] |= PollSet::POLL_ERROR;

there's a condition where the wepoll can return

 if (afd_events & AFD_POLL_RECEIVE_EXPEDITED)
   epoll_events |= EPOLLPRI | EPOLLRDBAND;

or

if (afd_events & AFD_POLL_ABORT)
  epoll_events |= EPOLLHUP;

In that situation the PollSet check do not intercept any valid result, but the wepoll do not wait on timeout so a socket reactor can end up in a while(1) situation. My specific case was EPOLLHUP that is not catched (I think the correct way here is a POLL_ERROR, but probably even EPOLLPRI | EPOLLRDBAND could be hadled with a POLL_READ