It would be useful to be able to pass a socket to multiple applications/ multiple instances of an application. Systemd, rather than just passing off the socket to a single process, would hold on to it's reference & be able to pass it to new instances. This would allow systemd to support technologies such as fcgi daemons or node.js instances, where each process is a listening daemon, but only able to serve a limited number of connections, and sharing of the listening socket is desired.
SO_REUSEPORT is ragingly popular all of a sudden, and demonstrates the sensibility conveyed here: let multiple programs run independently, to help service the same port.
A bit more SO_REUSEPORT in the news- "On top of that, last year we added a lot more headroom to our future growth by enabling the marvelous SO_REUSEPORT, a new flag available in Linux 3.9+ that allows several threads to bind the same port simultaneously instead of having to race for the same socket, having the kernel round-robin between them." http://githubengineering.com/brubeck/ "With the SO_REUSEPORT option enabled, there are multiple socket listeners for each IP address and port combination, one for each worker process. The kernel determines which available socket listener (and by implication, which worker) gets the connection. This can reduce lock contention between workers accepting new connections, and improve performance on multicore systems." http://nginx.com/blog/socket-sharding-nginx-release-1-9-1/ But I'm starting to think this RFE is incorrect. SO_REUSEPORT is all about allowing new instances to start independently and bind to the existing port: it's explicitly about *not* passing the same socket around to a bunch of children. Alternatively, systemd might be able to do socket-activation with indepedent so_reuseport 'ed sockets, creating a socket for each service-instance.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.