3 ms·

You're describing binding sockets for other processes, which is a great feature and has been standard practice since forever. You also get socket activation, f

• falcolas 12y ago
  > standard practice since forever Within individual process trees, yes. Across all process trees via the init system, not so much. I agree that it is a very useful thing to do and has been technically possible forever (since spawned processes need to have their inherited file handles over 2 intentionally closed), but it adds a bit of uncertainty and unnecessary coupling when it starts crossing the (admittedly arbitrary) process role boundary. The benefit of faster startup time is negligible for the typical non-desktop. > You also get socket activation, for free. Socket activation has been available for many (10+) years via xinitd, but it is infrequently used for a variety of reasons. For one, it's slow. The time required to spin up a new process to handle the requested information is non-0, particularly in cases where socket activation is most likely to be used (shell scripts, Python/Ruby/Node applications). This is OK for services used only occasionally, but for any frequently used service it is usually unacceptable. Plus, the overhead of keeping an occasionally-used service running in memory and listening to its own socket is typically pretty low, yet it provides the benefit of knowing exactly what is responding to a given socket.