softprops / hyperlocal

🔌 ✨rustlang hyper bindings for local unix domain sockets
MIT License
229 stars 46 forks source link

Backport hyperlocal windows #21

Open softprops opened 5 years ago

softprops commented 5 years ago

https://github.com/Azure/hyperlocal-windows

samscott89 commented 5 years ago

Alternatively/in addition would you consider using something like parity-toko-ipc to get support for windows named pipes?

arsing commented 4 years ago

FYI, we're unlikely to update that repo for tokio 0.2. The only reason it works is because of hacks we had to make to mio-uds and tokio-uds to make those work on Windows, and those hacks won't work with tokio 0.2. mio 0.7 may provide a better way to work with AF_UNIX sockets (ref), but it's not clear to us when that's going to happen in mio 0.7 and when tokio is going to update from mio 0.6 to 0.7

(I've been experimenting with an alternative at https://github.com/arsing/hyper-uds that bypasses the whole issue by just spawning two threads per connection and using blocking calls. It's likely that this will be good enough for our needs, so we might just switch our code to that.)

Macil commented 1 year ago

hyperlocal-windows looked outdated and I wasn't sure how difficult it would be to update it, so I've made my own fork of hyperlocal with Windows support and published it to crates.io: hyperlocal-with-windows. This package is cross-platform, supporting Windows and non-Windows platforms as before.

I'm not sure if I should submit my implementation as a PR into hyperlocal as it's a bit of a quick hack: I make tokio::net::TcpStream objects out of Unix sockets because tokio::net::UnixStream isn't implemented on Windows (https://github.com/tokio-rs/tokio/issues/2201), and I start a thread to accept connections from UnixListeners. It seems like it works out, though I don't have closing the UnixListener implemented for when the hyper server is closed, which is fine for the usual case of a process which listens on a Unix socket until it exits.

One other Windows issue my fork solves is that it provides a helper function for correctly (and asynchronously) deleting a Unix socket, which needs a small bit of special handling on Windows, and the README example is updated to use it.

softprops commented 1 month ago

@Macil I'm cleaning out the attic of issues here. I'd be happy to take a patch for that if you were for it