Signals in Operating Systems

A Brief, Asynchronous Notification, Not a Data Channel

Unlike the previous IPC mechanisms in this section, which are all designed to transfer actual data, a signal is a lightweight, asynchronous notification sent to a process to alert it that a specific event has occurred - it carries almost no data of its own, just the fact that something happened.

Some Common, Well-Known Signals

Three Ways a Process Can Respond to a Signal

• Default action - let the OS's built-in default behavior for that signal happen (often terminating the process).
• Custom handler - run a specific function the program has registered, to handle that signal in its own particular way.
• Ignore - explicitly disregard the signal entirely (though certain signals, like SIGKILL, cannot be ignored no matter what).

Why "Asynchronous" Is the Key Defining Property

A process is in the middle of executing some ordinary code...
        |
   [ SIGNAL arrives, interrupting normal execution ]
        |
   Signal handler runs (if one is registered)
        |
   Normal execution resumes where it left off (unless the signal terminated it)

A signal can arrive at essentially any moment during a process's execution, interrupting whatever it was doing - a fundamentally different communication model than the other IPC mechanisms covered in this section, which are typically read deliberately, whenever a process chooses to check for new data.

Why Signals Are a Genuinely Important, Distinct Category

Signals provide a way to handle urgent, time-sensitive events (like a user pressing Ctrl+C, or a critical error condition) that a process needs to react to essentially immediately - a different job from transferring bulk data, which is exactly what pipes, message queues and shared memory are actually built for.