Signal Handling - Linux

A program running always face unexpected situations, running out of memory, lost network connectivity, losing permissions, read write errors etc.
Therefore a robust program should be resilient to these conditions and should gracefully exit if the program cannot continue.
Signals should be handled....

I found this to be extremely resourceful and I'll just give a summary of what the author Alex says.....

• Signal is a notification, a message sent by either operating system or some application to your program (or one of its threads).
• In addition to informative nature of signals, they also interrupt your program. I.e to handle a signal, one of the threads in your program, stops its execution and temporarily switches to signal handler.
• Signals, as their name implies, used to signal something. There are several types of signals, each indicating something of its own. For instance SIGINT that I already mentioned, tells your program that someone tries to interrupt it with CTRL-C.

Some important signal sources. Each signals has a number. e.g. SIGKILL 9

• SIGHUP
  This signal indicates that someone has killed the controlling terminal. For instance, lets say our program runs in xterm or in gnome-terminal. When someone kills the terminal program, without killing applications running inside of terminal window, operating system sends SIGHUP to the program. Default handler for this signal will terminate your program.
• SIGINT
  This is the signal that being sent to your application when it is running in a foreground in a terminal and someone presses CTRL-C. Default handler of this signal will quietly terminate your program.
• SIGABRT
  Abort signal means you used used abort() API inside of your program. It is yet another method to terminate your program. abort() issues SIGABRT signal which in its term terminates your program (unless handled by your custom handler). It is up to you to decide whether you want to use abort() or not.
• SIGSEGV
  This is an exception signal as well. Operating system sends a program this signal when it tries to access memory that does not belong to it.
• SIGPIPE
  Broken pipe. As documentation states, this signal sent to your program when you try to write into pipe (another IPC) with no readers on the other side.
• SIGTERM
  This signal tells your program to terminate itself. Consider this as a signal to cleanly shut down while SIGKILL is an abnormal termination signal.

• Note : So if you do nohup ./a.out & and close the terminal the process will be alive because the SIGHUP will be ignored. If you say nohup ./a.out and press CTRL-C the program will terminate because it receives SIGINT; if you close the terminal the program will still run because SIGHUP is handled now.
• You can you signal handlers to mask the signals and take appropriate actions.
• You cannot handle SIGKILL and SIGSTOP
• sigaction() is better and portable than signal() to handle signals
• Signal handlers should exit asap and should not take any complex logical decisions. They are like ISR s.

 Signal Handling in Multi-threaded Applications

From this answer.

• Signal handlers are per-process state - that is, all the threads in a process share the same set of installed signal handler functions.
• Signal masks are per-thread state. Signals can be blocked or unblocked on a per-thread basis.
  Signals can be process- or thread-directed. That is if a certain thread executes the call signal(SIG_XXX, signalhandler) that thread handles that signal.
• If a signal is process-directed, then an arbitrary thread which does not have the signal blocked is chosen to handle it.

A simple way to handle signals in a multi-threaded application is to create one thread as a dedicated signal-handling thread. All signals of interest are blocked in every thread; no signal handlers are established; and the signal-handling thread calls sigwaitinfo() in a loop, acting on the signals as they're received.
sigwaitinfo() suspends execution of the calling thread until one of the signals in set is pending (If one of the signals in set is already pending for the calling thread, sigwaitinfo() will return immediately.)

This means that our signal handling thread is stopped until it receives a signal and when it does it will server that signal and return and because we call sigwaitinfo() in a loop it will listen forever for signals.... :-)
Because all other threads mask every interested signal we can guarantee only our signal handling thread does signal handling.