the system to send it certain signals: Ctrl-C (in older Unixes, DEL) sends an INT signal ("interrupt", SIGINT); by default, this causes the process to terminate. Ctrl-Z sends a TSTP signal ("terminal stop", SIGTSTP); by default, this causes the process to suspend execution. Ctrl-\ sends a QUIT signal (SIGQUIT); by default, this causes the process to terminate and dump core. Ctrl-T (not supported on all UNIXes) sends an INFO signal (SIGINFO); by default, and if supported by the command, this causes the operating system to show information about the running command. These default key combinations with modern operating systems can be changed with the command. Handling signals Signal handlers can be installed with the or system call. If a signal handler is not installed for a particular signal, the default handler is used. Otherwise the signal is intercepted and the signal handler is invoked. The process can also specify two default behaviors, without creating a handler: ignore the signal (SIG_IGN) and use the default signal handler (SIG_DFL). There are two signals which cannot be intercepted and handled: SIGKILL and SIGSTOP. Risks Signal handling is vulnerable to race conditions. As signals are asynchronous, another signal (even of the same type) can be delivered to the process during execution of the signal handling routine. The call can be used to block and unblock delivery of signals. Blocked signals are not delivered to the process until unblocked. Signals that cannot be ignored (SIGKILL and SIGSTOP) cannot be blocked. Signals can cause the interruption of a system call in progress, leaving it to the application to manage a non-transparent restart. Signal handlers should be written in a way that does not result in any unwanted side-effects, e.g. alteration, signal mask alteration, signal disposition change, and other global process attribute changes. Use of non-reentrant functions, e.g., or , inside signal handlers is also unsafe. In particular, the POSIX specification and the Linux man page require that all system functions directly or indirectly called from a signal function are async-signal safe. The man page gives a list of such async-signal safe system functions (practically the system calls), otherwise it is an undefined behavior. It is suggested to simply set some variable in a signal handler, and to test it elsewhere. Signal handlers can instead put the signal into a queue and immediately return. The main thread will then continue "uninterrupted" until signals are taken from the