Next: Signal Sets, Up: Blocking Signals [Contents][Index]
Temporary blocking of signals with sigprocmask gives you a way to
prevent interrupts during critical parts of your code. If signals
arrive in that part of the program, they are delivered later, after you
unblock them.
One example where this is useful is for sharing data between a signal
handler and the rest of the program. If the type of the data is not
sig_atomic_t (see Atomic Data Access and Signal Handling), then the signal
handler could run when the rest of the program has only half finished
reading or writing the data. This would lead to confusing consequences.
To make the program reliable, you can prevent the signal handler from running while the rest of the program is examining or modifying that data—by blocking the appropriate signal around the parts of the program that touch the data.
Blocking signals is also necessary when you want to perform a certain
action only if a signal has not arrived. Suppose that the handler for
the signal sets a flag of type sig_atomic_t; you would like to
test the flag and perform the action if the flag is not set. This is
unreliable. Suppose the signal is delivered immediately after you test
the flag, but before the consequent action: then the program will
perform the action even though the signal has arrived.
The only way to test reliably for whether a signal has yet arrived is to test while the signal is blocked.