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. > use of SIGCHLD and SIGWINCH for non-termination conditions is also > vital. How else should an operating system or desktop environment > inform a process of something important? I never use SIGCHLD. Instead I leave a pipe open between the child and the parent and notice an EOF on the pipe as the child exits. The pipe (or socketpair) is handy for other IPC as well. The signalfd mechanism in newer Linux kernels might make signals borderline usable. However, code that relies on signals had better meticulously call sigprocmask(2) and understand the precise points where signals should be let through. Another thing: this is a C programming issue, but functions like fprintf() should never be used together with signals: <URL: http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/200 6-05/msg00356.html> Marko -- https://mail.python.org/mailman/listinfo/python-list