Reputation: 15003
The sa_mask
field of struct sigaction
specifies signals that are blocked during handler invocation. Those signals are added to the process block mask just before the handler is invoked and removed right after handler completion. What if sa_mask
and the process signal mask overlap? Will those signals that are masked both by sa_mask
and the process signal mask be removed from the process signal mask?
Upvotes: 2
Views: 1711
Reputation: 215557
When a signal handler returns, the signal mask that was in effect before the signal was handled gets restored atomically as part of the return process. This will happen unless you jump out of the signal handler with longjmp
or siglongjmp
, in which case it's up to you whether you want to manually save and restore the signal mask.
As an interesting aside, if you use the SA_SIGINFO
flag to setup a three-argument-form signal handler, the ucontext_t
pointed to by the third argument contains a sigset_t uc_sigmask
member reflecting the saved signal mask. Further, I'm not sure whether this usage is sanctioned by POSIX, but on all real-world systems I know of, you can actually modify uc_sigmask
before returning from the signal handler to set a different signal mask (as opposed to restoring the original one) when the signal handler returns. This can be used, for example, if you want to re-raise the signal you just handled but leave it blocked when returning, so that it actually gets handled later on when the signal is again unblocked by the interrupted code or when sigwaitinfo
or similar is called.
Upvotes: 7
Reputation: 47770
Will those signals that are masked both by sa_mask and the process signal mask be removed from the process signal mask?
No. The original signal mask is restored, ie. what was blocked before would be blocked after.
Upvotes: 2