Mandalika's scratchpad [ Work blog @Oracle | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14  07.14  09.14  10.14  11.14  12.14  01.15  02.15  03.15  04.15  06.15  09.15  12.15  01.16  03.16  04.16  05.16  06.16  07.16  08.16  09.16  12.16  01.17  02.17  03.17  04.17  06.17  07.17  08.17  09.17  10.17  12.17  01.18  02.18  03.18  04.18  05.18  06.18  07.18  08.18  09.18  11.18  12.18  01.19  02.19  05.19  06.19  08.19  10.19  11.19  05.20  10.20  11.20  12.20  09.21  11.21  12.22 


Thursday, June 02, 2005
 
UNIX: Writing a Signal Handler

What is a signal?

A signal is a software interrupt, sent to a process to notify that an event has occured. Signals are usually sent by the Operating System (kernel) to notify processes that some event has occurred. Due to this, the processes need not poll for a particular event. By their nature, signals interrupt whatever the process is doing at that moment, and force it to handle them immediately. Because events may occur asynchronously, it is a good practice for the process to handle all the relevant signals using the API provided by the OS.

For example, the user may want to stop the process any time by pressing Control-C, which results in SIGINT signal.

Each signal has an integer number, as well as a symbolic name associated with it. Usually these are defined in /usr/include/sys/iso/signal_iso.h header file on Solaris. Note that we have to include /usr/include/signal.h file in our C/C++ programs, if we are going to use the signal API.

There are about 25 different kinds of signals, depending on the flavor of the system. Use the command kill -l, to get the list of signals supported by your system.

%uname -a
SunOS Govinda 5.9 Generic_118558-02 sun4u sparc SUNW,Ultra-Enterprise

% kill -l
HUP INT QUIT ILL TRAP ABRT EMT FPE
KILL BUS SEGV SYS PIPE ALRM TERM USR1
USR2 CLD PWR WINCH URG POLL STOP TSTP
CONT TTIN TTOU VTALRM PROF XCPU XFSZ WAITING
LWP FREEZE THAW CANCEL LOST XRES RTMIN RTMIN+1
RTMIN+2 RTMIN+3 RTMAX-3 RTMAX-2 RTMAX-1 RTMAX

For some signals, the default behavior is to ignore the signal. For others, the default behavior is to terminate the process.

Some terminating signals also produce the image of the memory layout (aka core) of the process when it was terminated. The core file will be useful for debugging. On Solaris, the behavior of all the signals was documented in /usr/include/sys/iso/signal_iso.h file.

The process can catch most of the signals except for a few. The process cannot catch SIGKILL & SIGSTOP signals. When the process receives such signals, it will be terminated.

If the program does not install any signal handlers, the run-time environment sets up a set of default signal handlers for the program. For example, the default signal handler for the TERM signal calls the exit() system call. The default handler for the ABRT is to dump the process's memory image into a file named core in the process's current directory, and then exit.

The signal handler is a function that gets called when the process receives a signal. The function is called in asynchronous mode, meaning that no where in the program you have code that calls this function directly. Instead, when the signal is sent to the process, the OS stops the execution of the process, and forces it to call the signal handler function. When the signal handler function returns, the process continues execution from wherever it happened to be before the signal was received. Failing to properly handle various signals, would likely cause our application to terminate, when it receives such signals.

The process can install its own signal handler to change the default behavior of any signal, except for SIGTERM.

Examples

Sending signals
---------------

Signals can be sent using keyboard (Ctrl-C, Ctrl-Z etc.,), command line with kill -<signal> <PID> (eg., kill -9 1234, kills the process with PID 1234) or using system calls.

The following C program shows how to send signals with kill() system call

% cat sendsignal.c
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>

int main() {
pid_t my_pid = getpid();
printf("\nMy process id (PID) = %d. Killing myself ..", my_pid);
kill(my_pid, SIGKILL);
return (0);
}

% cc -o sendsignal sendsignal.c
% ./sendsignal

My process id (PID) = 15031. Killing myself ..Killed


Simple signal handler
---------------------
The following trivial C program illustrates, how to write a simple signal handler

% cat signalhandler.c
#include <stdio.h>
#include <unistd.h>
#include <signal.h>

/*
* signal handler
*/

void CatchInterrupt (int signum) {
pid_t my_pid;

printf("\nReceived an interrupt! About to exit ..\n");
fflush(stdout);
my_pid = getpid();
kill(my_pid, SIGKILL);
}

int main(int argc, char** argv) {
/*
* Set the INT (Ctrl-C) signal handler to 'CatchInterrupt'
*/
signal(SIGINT, CatchInterrupt);

/*
* Do Nothing and wait for interrupts
*/
for ( ;; ) {}
}

% cc -o signalhandler signalhandler.c

% ./signalhandler
^C
Received an interrupt! About to exit ..
Killed

In the above program, the process simply waits in an infinite loop, for an interrupt event to occur and as soon as it receive one, it exits after printing a message on the console.

Note:
If the process should not die, and has to handle the signal whenever the event occurs, we have to reset (reinstall) the signal handler in CatchInterrupt() for it to catch the interrupt signals further. The modified code will be like this:

/*
* signal handler
*/

void CatchInterrupt (int signum) {
/*
* Reset the signal handler to catch interrupt again
*/
signal(SIGINT, CatchInterrupt);
printf("\nReceived an interrupt! Waiting for further interrupt signals ..\n");
fflush(stdout);
}

The behavior will be like this, after compiling and executing the code:

%./signalhandler
^C
Received an interrupt! Waiting for further interrupt signals ..
^C
Received an interrupt! Waiting for further interrupt signals ..
^C
Received an interrupt! Waiting for further interrupt signals ..
^C
Received an interrupt! Waiting for further interrupt signals ..
^Z
Stopped (user)


Reference:
Introduction To Unix Signals Programming

Technorati tag:


Comments:
thanks it helped in my assignment. simple and concise explanation
 
Unfortunately, while your example may work as an exercise, it will cause problems in real programs. Neither printf, nor fflush are async-safe, which means they cannot be safely invoked from within a signal handler. The results are undefined, and I have seen programs locking up because of this. Just an FYI.
 
Post a Comment



<< Home


2004-2019 

This page is powered by Blogger. Isn't yours?