does a blocked signal also a pending signal?

Viewed 622

we know that applications can explicitly block and unblock selected signals using the sigprocmask function, so let's say we have used this function to block SIGINT, so the kernel sets the corresponding bit in the blocked vector. If we run the program and press Ctrl + C to send SIGINT, since this signal is currently blocked, there is no action to the process( the process won't be terminated).

My question is, even though this signal is blocked, will kernel also sets the corresponding bit in the pending vector so that when we unblock this signal, SIGINT in the pending will be immediately receiving by the process? or the previous SIGINT doesn't count and you have to trigger a new SIGINT?

1 Answers

I'm not sure how (or if) the behavior will vary from platform to platform, or library implementation to implementation, but:

https://man7.org/linux/man-pages/man7/signal.7.html

A signal may be blocked, which means that it will not be delivered until it is later unblocked. Between the time when it is generated and when it is delivered a signal is said to be pending.

So yes, to answer your question, the Ctl-C would be "pending", and should be delivered if you unblock SIGINT.

It's also worth considering sigaction(), which would allow your process to completely ignore the signal.

Related