Hacker News new | past | comments | ask | show | jobs | submit login

Does this issue exist in servers like Unicorn? A new instance forks from the old one, inheriting sockets, and starts handling requests.

http://unicorn.bogomips.org/SIGNALS.html




I suspect inherited sockets across forks don't exhibit this, if a test done by Nicholas Grilly described on the haproxy mailing list [0] is to be believed (no code though, but shouldn't be hard to reproduce).

One thing that makes doing this in haproxy difficult is that there is not really any shared state between the parent and child processes, so the child doesn't have a good way to know which file descriptor maps to which listening endpoint in the configuration, since the child pretty much throws its entire state away and reads the config file anew. It's not that there can't be any shared state, but that's not how it's been architected. Finding out the endpoint via something like getsockname(2) might be doable, but the mapping of listening endpoints to listen configuration blocks isn't one-to-one, so it's actually "safer" (from an amount of code standpoint) to use SO_REUSEPORT and let the OS handling the shared listening.

[0] http://permalink.gmane.org/gmane.comp.web.haproxy/14143




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: