Windows UDS

[Timiz0r]

Adds Windows UDS (AF_UNIX SOCK_STREAM) support.

#1609

Windows doesn't support...

• SOCK_DGRAM, SOCK_SEQPACKET
• Abstract namespaces
• socketpair
• And I'm sure some other minor differences

Kept platform-specific code to a minimum (aside from mio::sys::windows::uds), and the tests are also largely intact. Of course, since there's a feature gap in Windows, some minor platform-specific changes have snuck in.

[Timiz0r]

Don't mean to keep it like this (and accept_blocking) -- where we switched off std:: types since they aren't stabilized for Windows yet. Mostly inclined to rewrite this function, but still thinking

[Thomasdezeeuw]

Mio follows the same (as best we can) API as std lib, since it's still unstable: rust-lang/rust#150487, I think we should wait until it's stable so we can match the API.

[Thomasdezeeuw]

Also for cross-referencing some previous prs:

• Adds support for UnixStream and UnixListener on Windows #1610
• Adds support for UnixStream and UnixListener on Windows #1667
• Add Windows support for Unix Domain Sockets #1914

[Timiz0r]

Since this is meant to be temporary, probably shouldn't be mio::net::uds::SocketAddr. Would want to decide on a suitable path that conveys temporariness.

[Timiz0r]

Mio follows the same (as best we can) API as std lib, since it's still unstable: rust-lang/rust#150487, I think we should wait until it's stable so we can match the API.

Fair of course, and I'll not fight the guidance of maintainers!

My 2c:

• Since we (barely) reference std lib (really only from_std functions), we're not necessarily blocked of course
• I can't imagine any drastic public interface changes happening to std::os::windows::net, that would then also affect mio. At least, I'm happy with the API over there, and everyone wants to keep it as identical as possible to the unix impl.
• SocketAddr is definitely an interesting design problem. If we temporarily added it for Windows, it still makes things awkward when it comes time to remove it.

And a couple more thoughts on SocketAddr:

• Could add in a type alias for unix and make it permanent
• Could just remove SocketAddr and make bind_addr and connect_addr unix-only.
• Certainly became less warm to adding a temp type the more I thought these other two options

Edit:
I also have a working mio implementation (uses TcpStream as a means of getting access to IoSource behavior), as well as a Tokio implementation (obnoxiously hacky, unfortunately), so I'm not blocked on having these features upstreamed to mio and Tokio!

[Thomasdezeeuw]

• Since we (barely) reference std lib (really only from_std functions), we're not necessarily blocked of course

We decided on following the std lib API because we had to draw the line somewhere on what to support and what not, it's not related to the std lib APIs we use or not. Also see the socket2 library for way more socket option that are not limited to Mio's implementation (but work with it).

• I can't imagine any drastic public interface changes happening to std::os::windows::net, that would then also affect mio. At least, I'm happy with the API over there, and everyone wants to keep it as identical as possible to the unix impl.

Maybe, but I prefer to wait. Furthermore, in my opinion, since the Unix and Windows implementations are now effectively the same I don't think they should live under std::os::. But the std library maintainers currently hold a different opinion, which is fine, but it might change at some point.

• SocketAddr is definitely an interesting design problem. If we temporarily added it for Windows, it still makes things awkward when it comes time to remove it.

And a couple more thoughts on SocketAddr:

• Could add in a type alias for unix and make it permanent
• Could just remove SocketAddr and make bind_addr and connect_addr unix-only.
• Certainly became less warm to adding a temp type the more I thought these other two options

Since std::os::unix::net::SocketAddr and std::os::windows::net::SocketAddr have the same API (with the exception of std::os::linux::net::SocketAddrExt, which is Linux only), I think a type alias makes sense. But really, the same arguments that apply here apply to the std lib making the two types one 🤷

[Timiz0r]

Yeah I can see both sides to std::os and std::net / "windows-enabled std::os::unix" (my didn't-think-too-hard-about-it-vote). Actually, curious about which you prefer (or none of the above?)!

I wonder if we can point to this PR (which demoes the likely eventual mio [and Tokio] API surface) to see if they'll reconsider the std::os::windows::net decision 🤔

In any case, I'll leave the PR up a week for more feedback in case others have an opinion and close it if nothing changes. And update the issue! I probably won't be the one to push for quicker mio and Tokio chances since I have a working solution on my end 🙂.

[Thomasdezeeuw]

Yeah I can see both sides to std::os and std::net / "windows-enabled std::os::unix" (my didn't-think-too-hard-about-it-vote). Actually, curious about which you prefer (or none of the above?)!

I think the Unix* types should live in std::net, that's what I would like for Mio as well.

I wonder if we can point to this PR (which demoes the likely eventual mio [and Tokio] API surface) to see if they'll reconsider the std::os::windows::net decision 🤔

In any case, I'll leave the PR up a week for more feedback in case others have an opinion and close it if nothing changes. And update the issue! I probably won't be the one to push for quicker mio and Tokio chances since I have a working solution on my end 🙂.

👍

[Timiz0r]

A bit late, but will close the PR as mentioned!