Hi. I looked into this some more and you might want to try removing any LSP that are installed. According to the wepoll project these can interfere with the event handling and registration.
> On Feb 11, 2026, at 3:54 PM, robert engels <[email protected]> wrote: > > > Btw, Go - which has a similar design to VT - on windows uses IO completion > ports. It uses epoll on Linux and kqueue on OSX. > >>> On Feb 11, 2026, at 2:50 PM, robert engels <[email protected]> wrote: >>> >> >> I must be misunderstanding the bug because this section although it is using >> distinct poll descriptors (for read and write), it is also having multiple >> threads register for events at the same time - which seems racy to me. >> >> “ Each epoll handle has a dedicated thread that runs epoll_wait in a loop, >> and schedules tasks to run in other threads in response to polled events. >> Other threads register interest ops with EPOLL_CTL_ADD, and when the event >> is polled, deregister interest with EPOLL_CTL_DEL. Any given socket handle >> can be registered at most once with each of the above epoll handles, once >> for reading, once for writing.” >> >> >>>> On Feb 11, 2026, at 1:15 PM, Alan Bateman <[email protected]> wrote: >>>> >>> On 11/02/2026 18:52, robert engels wrote: >>>> But the bug you linked as a potential candidate uses epoll directly. I >>>> only linked it because it discusses what sounds to be similar race results >>>> in starvation conditions. >>> The issue that I think Matthew may be hitting arises when a Windows SOCKET >>> that is registered for different I/O events with 2 AFD instances (think >>> registered with a Read-Poller and Write-Poller at the same time). So very >>> different to sharing epfd across threads or the edge triggered mode that >>> the article is about. >>> >>> -Alan
