On 12/9/25 06:04, Alyssa Ross wrote:
Alyssa Ross <hi@alyssa.is> writes:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/9/25 05:55, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
On 12/8/25 19:38, Alyssa Ross wrote:
This means we can use readiness notification to wait until the sockets are created without having to add special functionality for that to the router program, and also means we can do extra system-specific setup to the sockets, like changing their owners, outside of the router.
Since the socket paths were the only arguments taken by the router, this also lets us drop the clap dependency entirely.
I strongly recommend open-coding the file descriptor stuff instead of using a third-party library for it. It's just a two calls to getsockopt() (SO_DOMAIN and SO_TYPE) per socket, and listenfd pulls in wasm-bindgen and js-sys!
It pulls in wasm-bindgen and js-sys if you're building for those platforms, which we are not. An inert mention in Cargo.lock is not a problem. The only dependency of listenfd in our context (checked via cargo tree) is on libc, which is already a dependency of tokio.
I've implemented systemd socket activation in Rust before, and it's not at all nice, even with libsystemd. listenfd adds 295 extra lines of code in total. I think that's worth it.
Ah, I didn't mean to actually implement the whole thing, but rather to open-code the specific case used here.
If listenfd is a very popular crate, I'd go with it. Otherwise, I'd be too concerned about supply-chain risk. On the other hand, I might be too used to having to use Fedora and Debian packages for my Rust dependencies.
"#28 in Unix APIs", ahead of landlock and just behind libseccomp.
(And also packaged by both Fedora and Debian.)
Go ahead and use it then! -- Sincerely, Demi Marie Obenour (she/her/hers)