| Summary: | RFE: Pass a socket to multiple application instances | ||
|---|---|---|---|
| Product: | systemd | Reporter: | rektide |
| Component: | general | Assignee: | systemd-bugs |
| Status: | NEW --- | QA Contact: | systemd-bugs |
| Severity: | enhancement | ||
| Priority: | medium | CC: | rektide |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
rektide
2013-01-26 20:27:05 UTC
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.