Skip to main content

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.

Comments

Post a Comment

Popular posts from this blog

Detaching a process from terminal - exec(), system(), setsid() and nohup

Linux processes are created by fork() and exec(). The very first process of POSIX systems is init and subsequent processes are derived from the init as parent. These subsequent processes are child processes. During forking the parent process copies itself - with all I/O, address space, stack, everything. The only thing that is different is the process ID. The parent and child will have 2 different process IDs. The system() library function uses fork(2) to create a child process that executes the shell command specified in command using execl(3) as follows: execl("/bin/sh", "sh", "-c", command, (char *) 0); system() returns after the command has been completed. system() executes a command specified in command by calling /bin/sh -c command , and returns after the command has been completed. During execution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.  system() calls are often made within programs to execut...
Post a Comment
Read more

Vaadin vs GWT

From Chapter 1 of book of Vaadin I quote the following. Vaadin Framework is a Java web application development framework that is designed to make creation and maintenance of high quality web-based user interfaces easy. Vaadin supports two different programming models: server-side and client-side . The server-driven programming model is the more powerful one . It lets you forget the web and program user interfaces much like you would program a desktop application with conventional Java toolkits such as AWT, Swing, or SWT. But easier. While traditional web programming is a fun way to spend your time learning new web technologies, you probably want to be productive and concentrate on the application logic. The server-side Vaadin framework takes care of managing the user interface in the browser and the AJAX communications between the browser and the server . With the Vaadin approach, you do not need to learn and deal directly with browser technologies, such as HTML or JavaScript. ...
3 comments
Read more

C++ Callbacks using function pointers vs boost bind +boost function

In C, the most common uses of callbacks are as parameters to library functions like qsort , and as callbacks for Windows functions, etc. For example you might have a library that provides some sorting functions but you want to allow the library user to provide his own sorting function. Since the arguments and the return values do not change depending on the sorting algorithm, this can be facilitated in a convenient manner using function callbacks. Callbacks are also used as event listeners. onMouseClick(), onTerminalInput(), onData(), onConnectionStatus(), onRead() are probably some examples you've already seen in different libraries. The libraries have these callback functions and the users of the library are supposed to implement them. The library has a function pointer to these functions and calls them on their event loop which will invoke the code of the inherited classes of the library user. The implementation of function pointers is simple: they are just "code p...
Post a Comment
Read more