Shell Execution of Programs Process Groups, Session and Signals 1
Signal Concepts Signals are a way for a process to be notified of asynchronous events (software interrupts). Some examples: a timer you set has gone off (SIGALRM) some I/O you requested has occurred (SIGIO) a user resized the terminal window (SIGWINCH) a user disconnected from the system (SIGHUP)... The process can t simply test a variable (such as errno) to see whether a signal has occurred; instead, the process has to tell the kernel if and when this signal occurs, do the following. ). See also: signal(2)/signal(3)/signal(7) (note: these man pages vary significantly across platforms!) Process Groups, Session and Signals 2
Signal Concepts Besides the asynchronous events listed previously, there are many ways to generate a signal: terminal generated signals (user presses a key combination which causes the terminal driver to generate a signal) hardware exceptions (divide by 0, invalid memory references, etc) kill(1) allows a user to send any signal to any process (if the user is the owner or superuser) kill(2) (a system call, not the Unix command) performs the same task software conditions (other side of a pipe no longer exists, urgent data has arrived on a network file descriptor, etc.) Process Groups, Session and Signals 3
Signals Process Groups, Session and Signals 4
Signals Process Groups, Session and Signals 5
Signal Concepts Once we get a signal, we can do one of several things: Ignore it. (note: there are some signals which we CANNOT or SHOULD NOT ignore) Catch it. That is, have the kernel call a function which we define whenever the signal occurs. Accept the default. Have the kernel do whatever is defined as the default action for this signal Process Groups, Session and Signals 6
signal(3) Establish a signal handler. func can be: SIG IGN which requests that we ignore the signal signo SIG DFL which requests that we accept the default action for signal signo or the address of a function which should catch or handle a signal Process Groups, Session and Signals 7
Signal Examples Process Groups, Session and Signals 8
Signal Examples Process Groups, Session and Signals 9
Program Startup When a program is executed, the status of all signals is either default or ignore. When a process fork(2)s, the child inherits the parent s signal dispositions. A limitation of the signal(3) function is that we can only determine the current disposition of a signal by changing the disposition. Process Groups, Session and Signals 10
Interrupted System Calls Some system calls can block for long periods of time (or forever). These include things like: read(2)s from files that can block (pipes, networks, terminals) write(2) to the same sort of files open(2) of a device that waits until a condition occurs (for example, a modem) pause(3), which purposefully puts a process to sleep until a signal occurs certain ioctl(3)s certain IPC functions Process Groups, Session and Signals 11
Interrupted System Calls Catching a signal during execution of one of these calls traditionally led to the process being aborted with an errno return of EINTR. This was done under the assumption that since a signal occurred and the process caught it, there is a good chance that something has happened that should wake up the blocked system call. Process Groups, Session and Signals 12
Interrupted System Calls Previously necessary code to handle EINTR: Nowadays, many Unix implementations automatically restart certain system calls. Process Groups, Session and Signals 13
Non-reentrant functions in signal hander Process Groups, Session and Signals 14
Non-reentrant functions in signal hander When this program was run, the results were random. The main function had called getpwnam, but that when getpwnam called free, the signal handler interrupted it and called getpwnam, which in turn called free. The data structures maintained by malloc and free had been corrupted when the signal handler (indirectly) called free while the main function was also calling free. Occasionally, the program would run for several seconds before crashing with a SIGSEGV error. Process Groups, Session and Signals 15
Reentrant Functions Process Groups, Session and Signals 16
kill(2) and raise(3) The kill function sends a signal to a process or a group of processes. pid > 0 signal is sent to the process whose PID is pid pid == 0 signal is sent to all processes whose process group ID equals the process group ID of the sender pid == -1 POSIX.1 leaves this undefined, BSD defines it (see kill(2)) The raise function allows a process to send a signal to itself. Process Groups, Session and Signals 17
alarm(2) and pause(2) The alarm function allows us to set a timer that will expire at a specified time in the future. When the timer expires, the SIGALRM signal is generated. If we ignore or don t catch this signal, its default action is to terminate the process. The pause function suspends the calling process until a signal is caught. Process Groups, Session and Signals 18
Signal Sets More advanced signal handling can be done via signal sets representing multiple signals Process Groups, Session and Signals 19
sigprocmask(2) The signal mask of a process is the set of signals currently blocked from delivery to that process. A process can examine its signal mask, change its signal mask, or perform both operations in one step by calling the sigprocmask() function. Process Groups, Session and Signals 20
sigpending(2) The sigpending function returns the set of signals that are blocked from delivery and currently pending for the calling process. Process Groups, Session and Signals 21
Process Groups, Session and Signals 22
Process Groups, Session and Signals 23
Process Groups, Session and Signals 24
sigaction(2) This function allows us to examine or modify the action associated with a particular signal. signal(3) is (nowadays) commonly implemented via sigaction(2). Process Groups, Session and Signals 25
An implementation of signal using sigaction Process Groups, Session and Signals 26
sigsuspend(2) The signal mask of the process is set to the value pointed to by sigmask. Then the process is suspended until a signal is caught or until a signal occurs that terminates the process. Two operations are executed in a single atomic operation.. Provides a correct way to protect a critical region of code from a specific signal. Process Groups, Session and Signals 27
Protecting a critical region from a signal Process Groups, Session and Signals 28
Protecting a critical region from a signal Process Groups, Session and Signals 29
Protecting a critical region from a signal Process Groups, Session and Signals 30
Parent-child synchronization with signal Process Groups, Session and Signals 31
Parent-child synchronization with signal Process Groups, Session and Signals 32
Parent-child synchronization with signal Process Groups, Session and Signals 33
abort(3) This function sends the SIGABRT signal to the caller. (Processes should not ignore this signal.) The intent of letting the process catch the SIGABRT is to allow it to perform any cleanup that it wants to do before the process terminates. Process Groups, Session and Signals 34
system() function handling signals Process Groups, Session and Signals 35
system() function handling signals Process Groups, Session and Signals 36
system() function handling signals Process Groups, Session and Signals 37
Correct implementation of system function Process Groups, Session and Signals 38
Process Groups, Session and Signals 39
sleep(3) This function causes the calling process to be suspended until either The amount of wall clock time specified by seconds has elapsed. A signal is caught by the process and the signal handler returns. Process Groups, Session and Signals 40
Signal Queuing Most UNIX systems don t queue signals. But some systems do. Signals arriving while a handler runs are queued unless they are blocked. Multiple identical signals are queued, but you can receive a different signal while in a signal handler. Process Groups, Session and Signals 41
Questions? Process Groups, Session and Signals 42