In this lesson, you will learn how the Linux kernel differentiates between "Standard" and "Real-Time" signals based on how it manages their delivery and queuing.
Standard Signals (The "Best-Effort" Approach)
Standard signals (numbered 1–31) are designed to notify a process that an event has occurred, but they are not designed to carry data or guarantee a count. If you send five SIGUSR1 signals to a process in rapid succession while the process is busy (blocked), the kernel will only deliver one of them. Because the process is busy, the kernel "marks" the signal as pending. Since there is only one "slot" for each standard signal type, subsequent signals of the same type are simply discarded. They provide no delivery guarantee beyond saying, "This happened at least once."
Real-Time Signals (The "Queued" Approach)
Real-Time signals (numbered 32–64) are designed for scenarios where you cannot afford to lose information. Unlike standard signals, real-time signals are queued by the kernel. If you send five SIGRTMIN signals to a process, the kernel places each one into a queue. The process will receive every single one of those signals in the order they were sent once it resumes execution.
Furthermore, real-time signals can carry a small amount of extra data (a sigval integer or pointer), which is useful for sending values alongside the signal notification.
Comparing the Behavior
Imagine a printer process. If you send a "Stop" command five times using a standard signal, the printer just stops—it doesn't care how many times you pressed the button. However, if you are sending data packets to be processed in order, using a standard signal would result in lost data.
Standard Signal (e.g., SIGUSR1):
[Signal 1] -> Process Busy -> [Signal 2] -> [Signal 3]
Result: Process receives only [Signal 1] and [Signal 3] (or just 1).
Real-Time Signal (e.g., SIGRTMIN):
[Signal 1] -> Process Busy -> [Signal 2] -> [Signal 3]
Result: Process queue holds [1, 2, 3]; all are delivered sequentially.
The key trade-off is overhead: because the kernel must maintain a queue and track additional data for real-time signals, they require more system resources than the simple, stateless standard signals.
Key Takeaway: Standard signals are for event notification where individual delivery is not guaranteed; Real-Time signals are for data-heavy tasks that require every single signal to be queued and delivered in order.