[EMAIL PROTECTED] (Paul Jarc) writes: >> The basic idea is that SIGUSR1 is reserved for use by the user, >> and it's intended to be a fairly fatal signal: if part of a >> multiprocess application doesn't know what to do with SIGUSR1, it's >> supposed to exit immediately. > > This would seem to make SIGUSR1 entirely redundant with SIGTERM.
To some extent yes, but they are different signals, and applications sometimes need more than one signal value. (Sometimes they need more than two, which is why there's a SIGUSR2. :-) Also, standard applications are required to clean up any temporary files when sent SIGTERM; they aren't required to do this for SIGUSR1 or SIGUSR2. There are a few other requirements for SIGTERM (e.g., "make x" is normally supposed to remove "x" if it's still building "x", when sent SIGTERM) that do not apply to SIGUSR1 and SIGUSR2. > As I read the previous quote, the restriction is on the kernel not > to *send* SIGUSR1 "spontaneously" (as it does with SIGSEGV, SIGHUP, > SIGCHLD, etc.), so that userspace programs can define their own > semantics for it, and they can rest assured that it won't be > triggered by some unrelated event that the kernel notices. Yes that's right. > (So I think dd would be allowed to do this too, if not for the > specific restriction on its own page; No, because the default for utilities (as specified in <http://www.opengroup.org/onlinepubs/007904975/utilities/xcu_chap01.html#tag_01_11> under "ASYNCHRONOUS EVENTS" is that a utility must immediately terminate when sent a SIGUSR1. > Maybe POSIXLY_CORRECT would be enough to satisfy the requirement? Yes, if we decide to depart from POSIX by default but conform if POSIXLY_CORRECT is set, that conforms. But I'd rather not resort to POSIXLY_CORRECT if I can avoid it. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
