Tracking Issue for Windows Unix Domain Sockets

[kouhe3]

Feature gate: #![feature(windows_unix_domain_sockets)]

This is a tracking issue for os::windows::net

Public API

use std::os::windows::net::{UnixStream, UnixListener};
let socket = UnixStream::connect("/tmp/sock")?;
let listener = UnixListener::bind("/tmp/socket")?;

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: UnixStream/UnixListener on Windows  #150428
• Final comment period (FCP)
• Stabilization PR
• close Unix domain sockets on Windows #56533

Unresolved Questions

• can't connect to abstract path issue

[lorenzleutgeb]

Thanks! I got a simple client/server demo to work on my machine using this. So I guess the GitHub label S-tracking-unimplemented is probably not appropriate anymore.

[lorenzleutgeb]

Given that @kouhe3 first attempted to get similar ideas into mio (see tokio-rs/mio#1914), I think the two prior PRs that also targeted mio should be considered and contrasted:

• Adds support for UnixStream and UnixListener on Windows tokio-rs/mio#1610
• Adds support for UnixStream and UnixListener on Windows tokio-rs/mio#1667

I mean that there might be some interesting differences in what was merged as #150428 and what was proposed to be added to mio before.

Other prior art:

• https://github.com/haraldh/rust_uds_windows
• https://github.com/Azure/mio-uds-windows

[lorenzleutgeb]

I think that there should be some tests that are neither #[cfg(windows)] like

rust/library/std/tests/windows_unix_socket.rs

Line 1 in 605f49b

#![cfg(windows)]

nor #[cfg(unix)] to provide at least some assurance that the API of the two variants is compatible.

[Thomasdezeeuw]

Are there any plans to merge the Unix and Windows variants? For example as std::net::{UnixStream, UnixListener}?

[lorenzleutgeb]

Are there any plans to merge the Unix and Windows variants? For example as std::net::{UnixStream, UnixListener}?

@Thomasdezeeuw, it looks like rust-lang/libs-team#271 (comment) might answer your question:

We discussed this in the libs-api meeting and we're happy to add this as a Windows-specific API under std::os::windows::net. We don't think this belongs under std::net because it is still fundamentally an OS-specific API.