Signals
Perl uses a simple signal-handling model: the %SIG hash contains
references (either symbolic or hard) to user-defined signal handlers.
Certain events cause the operating system to deliver a signal to the
affected process. The handler corresponding to that event is called with
one argument containing the name of the signal that triggered it. To send
a signal to another process, use the kill function. Think of it as sending a one-bit
piece of information to the other process.[155] If that process has installed a signal handler for that
signal, it can execute code when it receives the signal. But there’s no
way for the sending process to get any sort of return value, other than
knowing that the signal was legally sent. The sender receives no feedback
saying what, if anything, the receiving process did with the
signal.
We’ve classified this facility as a form of IPC, but, in fact, signals can come from various sources, not just other processes. A signal might also come from your own process, or it might be generated when the user at the keyboard types a particular sequence like Control-C or Control-Z, or it might be manufactured by the kernel when a special event transpires, such as when a child process exits, or when your process runs out of stack space or hits a file size or memory limit. But your own process can’t easily distinguish among these cases. A signal is like a package that arrives mysteriously on your doorstep with no return address. You’d best open it carefully. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access