Signals are standardized messages sent to a running program to trigger specific behavior, such as quitting or error handling.
They are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems.
Signals are similar to interrupts, the difference being that interrupts are mediated by the CPU and handled by the kernel while signals are mediated by the kernel (possibly via system calls) and handled by individual processes.
[citation needed] The kernel may pass an interrupt as a signal to the process that caused it (typical examples are SIGSEGV, SIGBUS, SIGILL and SIGFPE).
Typing certain key combinations at the controlling terminal of a running process causes the system to send it certain signals:[3] These default key combinations with modern operating systems can be changed with the stty command.
Signals can cause the interruption of a system call in progress, leaving it to the application to manage a non-transparent restart.
Use of non-reentrant functions, e.g., malloc or printf, inside signal handlers is also unsafe.
Signals should be processed from the queue on the main thread and not by worker pools, as that reintroduces the problem of asynchronicity.
In Unix-like operating systems, this event automatically changes the processor context to start executing a kernel exception handler.
In case of some exceptions, such as a page fault, the kernel has sufficient information to fully handle the event itself and resume the process's execution.
The table below lists some default actions for POSIX-compliant UNIX systems, such as FreeBSD, OpenBSD and Linux.