Signals
Software interrupts to a process: SIGINT, SIGCHLD, handlers, and async-signal-safety.
Level: intermediate
What is it?
A process signal is a small asynchronous notification delivered by the operating system to a process or thread. Common POSIX signals include SIGINT (often an interrupt request from a terminal), SIGTERM (a termination request), SIGCHLD (a child process changed state), and SIGKILL (an uncatchable termination request).
Why does it matter?
Signals allow processes to respond to events without polling continuously. They are intentionally limited notifications, not general message payloads, and their asynchronous behavior imposes strict rules on what a handler may safely do.
Mental model
Treat a signal as a doorbell, not a full message. It tells the process that something happened; the process may handle it, defer it, or be terminated according to the signal's disposition and platform rules.
How it works
- A signal can have a default action, be ignored where permitted, or be caught by a handler; SIGKILL and SIGSTOP cannot be caught or ignored.
- Standard signals may coalesce while pending, so they are not a reliable counter of every event; real-time signals have different queuing semantics.
- A signal handler can interrupt code at inconvenient points; only async-signal-safe operations are generally safe to call from a POSIX handler.
- SIGTERM requests orderly termination, while SIGKILL forces termination without application cleanup.
- Use sigaction-style APIs and carefully manage masks and shared state when handling signals.
Steps
- A user presses Ctrl+C in a terminal attached to a foreground process group.
- The terminal driver sends SIGINT to the foreground process group.
- The process's signal disposition determines whether the default action occurs or a handler runs.
- A robust application performs complex cleanup in normal control flow, using the handler only for minimal safe notification.
Real-world usage
- Handling graceful shutdown requests in command-line tools and services.
- Managing child-process lifecycle and reacting to SIGCHLD.
- Designing signal handling that avoids unsafe allocation, logging, or locking inside a handler.
Common mistakes
- Assuming every sent standard signal is queued as a separate event.
- Calling arbitrary functions or taking ordinary mutexes inside an asynchronous handler.
- Using SIGKILL when the application needs an opportunity to flush state or clean up.
Interview questions
How does SIGTERM differ from SIGKILL?
SIGTERM is a catchable termination request that an application can handle for cleanup. SIGKILL cannot be caught or ignored and forces termination.
Why are signal handlers restricted?
A signal can interrupt code while its internal state is inconsistent; calling non-async-signal-safe functions can deadlock or corrupt state.