Q: why did you say the signals sent are pending and there’s a delay in response?
%%A: if the target process is executing some special instructions the kernel won’t deliver the signal.
AA: For example waiting for network/disk IO — such a process may be almost unkillable. https://major.io/2010/03/18/sigterm-vs-sigkill/ says a reboot is required.
%%A: It’s possible that when target process gets a time slice it then gets a chance to check the “signal table”.
AA: A Unix signal is picked up only at start of a time slice by the recipient “cpu-driver”. See P126[[art of debugging]].
So I gave two correct answers to Olgun of Trexquant but he didn’t acknowledge. I also described the (common) scenario of a one-core machine. The signaling process need to give up the CPU before the receiving process can react to it.
Postman drops a letter on your doorstep when you are out. This is the best way to deliver the signal. It’s uncommon (impossible?) to interrupt a process /midstream/ a sequence of instructions. I guess the reason is efficiency — no efficient implementation of such a “real-time” interrupt mechanism. In Unix, what is common is the signal mechanism.
Pending signals for a parent process is not inherited by a forked child process.
Unix signals can be generated from interactive user, from any other process, from kernel or from hardware, but they all have a target PID.
Unix Signal is at a lower level than threading. Thread preemption often depends on Unix signals
Unix Signal is a kernel-level mechanism.
Unix Signals target a process, not a thread.
A Unix Signal is an event. A Signal handler is an event callback function whose address is associated with one specific signal.
keep learning 活到老学到老 