Bug ID: JDK-8279916 Reading from Pipe may hang on Windows

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

(on behalf of Alexey Pavlyutkin)

If a consumer is fast enough to read out all the data from a pipe and call WSARecv() again on empty socket then blocking WSARecv() call may ignore closing of producer's end and never returns. Accordingly to https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsarecv

{quote}
Windows Sockets 2 does not define any standard blocking time-out mechanism for this function. For protocols acting as byte-stream protocols the stack tries to return as much data as possible subject to the available buffer space and amount of received data available. However, receipt of a single byte is sufficient to unblock the caller.
{quote}

See the attached reproducer.

MS guys admitted potential problem in Winsock, but they said that it is complex and they are not going to fix it urgently. Unfortunately I could not submit issue to thier support.
03-03-2022
I just communicate in MS Q&A as yet https://docs.microsoft.com/en-us/answers/questions/700171/blocking-wsarecv-call-on-af-unix-socket-does-not-r.html
20-01-2022
That's good you have a native reproducer. Since RDP2 for JDK 18 is today, we decided to revert the Pipe impl on Windows to use TCP sockets. But, Unix domain socket channels are still available on Windows in the JDK and will benefit as soon as MS releases a fix for this. Have you submitted a bug report?
20-01-2022
See attached WSARecvHanger.cpp. It reproduces the issue within ~5-6 seconds
20-01-2022
[~apavlyutkin] Please coordinate with [~michaelm] as he is also working on a reproducer for Microsoft. We will likely change the Pipe implementation back to using TCP sockets until the underlying issue is resolved.
19-01-2022
I asked MS guys about that and in return they asked for C++ reproducer. Working on that
19-01-2022
Another workaround is to configure SO_RCVTIMEO option and wrap WSARecv call with infinite loop. I tried and it works
18-01-2022
The WSARecv on the reader side should fail with something like WSAECONNRESET when the pipe is closed on the writing side. It's not clear whether this is a Windows or JDK bug, but it only started happening after we switched the pipe implementation from TCP sockets to AF_UNIX. We may have to switch that back pending complete understanding of the issue.
17-01-2022
See also JDK-8278369 which may change the Pipe implementation on Windows back to using sockets.
12-01-2022
Any changes here will likely require significant discussion. It would be useful if you could start a discussion on nio-dev rather than a PR.
12-01-2022