RFR: 8267564: JDK-8252971 causes SPECjbb2015 socket exceptions on Windows when MKS is installed

[Alan Bateman]

On Thu, 3 Jun 2021 17:16:57 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This fixes a problem where unix domain sockets are available on Windows from third party winsock drivers (other than the Microsoft implementation in Windows 10/2019). These are available (unexpectedly) on earlier Windows releases and are not supported by Java. 
> 
> The fix is to search for the expected winsock service provider ID and specifically use that one when creating sockets. Previously, we just attempted to create a unix domain socket, and once that succeeded we assumed we had the right service provider.
> 
> I haven't included a regression test because the environment to reproduce the issue is not part of the standard test configuration. Also, the new code is well exercised by existing tests.
> 
> Thanks,
> Michael.

I don't object to select the MS provider but it strikes me that we are working around a bug in MKS. I wonder if there is a newer MKS version that fixes this, I also wonder if sockets created with their LSP can be multiplexed with other sockets from other providers.

src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 28:

> 26: #ifndef UNICODE
> 27: #define UNICODE 1
> 28: #endif

Setting UNICODE has wider impact, can you explain why you are adding this? Does it go away if WSASocketW is used instead?

src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 101:

> 99:     if (g1->Data3 != g2->Data3)
> 100:         return 0;
> 101:     return !memcmp(g1->Data4, g2->Data4, 8);

I think this would be easier to understand if Data4 were compared in the same way as Data1-Data3.

src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 140:

> 138:             break;
> 139:         }
> 140:     }

The control flow can be simplified to avoid having continue and break in the loop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4339