[ilyt]

It's definitely nice when it does but it's also a whole lot of complexity to add to the code. You have to re-create all structures relying on configs, reconnect if needed, clear all previous ones, but only after any ongoing processing of requests received before the reload signal finishes.

Some go half-way, like HAProxy where it does spawn a new process but that process just binds with SO_REUSEPORT and signal old one to close the socket and finish all remaining connections. So you effectively get hitless reload, it's just that old process is the one finishing in-flight requests

[withinboredom]

Yeah, it def adds complexity but if you want it used in real world applications, it’s a must-have. With only env vars, it’s an impossibility to ever have (without supporting infrastructure and processes), which was the point I was trying to make.

[ilyt]

Hardly. "Real world applications" need to tolerate single node failure anyway so reload functionality doesn't add all that much. Some system daemons, sure, them not working for a second can be disruptive so it is worthy endeavor there, but the amount of added complexity is nontrivial and the added complexity scales with apps' own complexity.

It's a bit different for desktop apps, as restarting app every time you change some config options would be far bigger PITA than some server app.

[withinboredom]

Unless you’re working for a tech company, it’s running on a single server (and it’s worth pointing out that most companies aren’t tech companies). That’s what I meant by “real world”, AKA, outside the tech bubble.