Wouldn’t it be better to tackle #8863 and implement this over PF_INET (although I’m suspicious as to why Microsoft avoided implementing socketpair that we’re missing something...)

The windows AF_UNIX sockets are not (at least they were/are not until writing of the blog post) feature-complete. Especially datagram support is missing. Also for implementation it would be helpful to have the autobind feature, which is also missing, but available and used in the AF_INET implementation I'm proposing.

https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

Summarizing from the above, the following Linux unix socket features are either currently unavailable or unsupported in the Windows unix socket implementation.

• AF_UNIX datagram (SOCK_DGRAM) or sequence packet (SOCK_SEQPACKET) socket type.
• Autobind feature (see the section on ‘sockaddr_un’ for details).
• socketpair: socketpair socket API is not supported in Winsock 2.0.

That's a lot of code that I don't fully understand. (The lack of any comment doesn't help.) Plus, in nearly 30 years of Unix systems programming, I never felt the need for socketpair, finding pipe enough for my needs. Is there a compelling use case for socketpair under Windows?

My use case is testing read/write I/O functions transferring data between bigarrays and Unix.file_descr. Like Unix.read / Unix.write those functions may need to work on winsock sockets. This code path can only be tested on sockets. That's my use case for socktpair. They are also used for message-based IPC. Pipes are streams and don't support message-based communication.

It is true that the windows pipe allows bidirectional communication like a SOCK_STREAM socketpair. But this is neither portable nor supported by our Unix module.

I added some comments explaining why the set_nonblock, EWOULDBLOCK juggling and the assertions are necessary.

I forgot about the bidirectional nature of socketpair, as opposed to the (normally) unidirectional pipe. Thanks for reminding me.

Thanks for your work on this! #10192 has been merged which does this using Unix sockets on Windows 10 1803+. Although that means there are some supported versions of Windows for which Unix.socketpair still isn't available, I don't think it's worth the maintenance weight of two emulations, so I'm closing this one.