On Fri, Aug 25, 2017 at 5:07 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: > Chris Angelico <ros...@gmail.com>: > >> On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >>> Signals are an arcane Unix communication method. I strongly recommend >>> against using signals for anything but terminating a process, and even >>> then you have to be extra careful. >>> >>> I have seen code that uses signals for runtime communication, but none >>> of it was free from race conditions. >> >> Strongly disagree. Signals exist so that they can be used. Sending >> SIGHUP to a daemon to tell it to reload its configs is well-supported >> by the ecosystem; > > The ancient SIGHUP reload antipattern is infamous: > > /bin/kill -HUP $MAINPID > > Note however that reloading a daemon by sending a signal (as with the > example line above) is usually not a good choice, because this is an > asynchronous operation and hence not suitable to order reloads of > multiple services against each other. It is strongly recommended to > set ExecReload= to a command that not only triggers a configuration > reload of the daemon, but also synchronously waits for it to > complete. > > <URL: https://www.freedesktop.org/software/systemd/man/systemd.servic > e.html> > > The SIGHUP practice makes automation painful. I want to reconfigure but > can't be sure when the new configuration has taken effect.
And yet, despite you calling it an antipattern, it's still very well supported. There are limitations to it - as you say, it's asynchronous - but it is the default for many services. SystemD is completely supporting it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
