Potential lost write IO notifications in Windows when using virtual threads

[robert engels]

It looks like the EPoll bug on windows is widely reported, but there also is a fair amount of critique of epoll in general. This article goes into depth on triggering events and various issues. My understanding though is that windows doesn’t even have a true epoll, on a layer over the native kernel event system. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/

> On Feb 11, 2026, at 10:27 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 11/02/2026 16:00, Matthew Swift wrote:
>> Hi,
>> 
>> I suspect that I've discovered a bug in the IO polling mechanism used by virtual threads on Windows. I've been able to systematically reproduce the problem on Windows 2016, 2019 and 2022 Intel x64 using both JDK 25.0.2 and 25.0.3 EA build 01, and also JDK 27 EA 8 build. The problem occurs when the server attempts to send a large response message to the client. The server's write operation becomes blocked and is never notified when the socket becomes writable again:
> 
> Can you determine if a blocking read outstanding on the same connection that another thread is blocked on the large write? Can you set SO_SNDBUF to a large value to see if that reduces or eliminates the sightings?
> 
> We have been chasing an issue in the Windows Ancillary Function Driver for winsock that arises when a Windows SOCKET is use with two different completion ports or AFD device handles at the same time. Daniel Jeliński has some good analysis here:
>   https://github.com/piscisaureus/wepoll/issues/35
> 
> We have a prototype poller implementation that works around this issue but it has some performance impact (on Windows) so have been slow to process it [1].
> 
> -Alan
> 
> [1] https://bugs.openjdk.org/browse/JDK-8334574
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260211/6803c331/attachment.htm>