this project is all about signals and kernel support for signals in unix

1. BANGALORE INSTITUTE OF TECHNOLOGY
DEPARTMENT OF INFORMATION SCIENCE & ENGINEERING
SUBMITTED BY:
ANJAN B 1BI20IS016
DASRHAN P 1BI20IS027
LAKSHMISHA R A 1BI20IS049
MANOJ B KULKARNI 1BI20IS052
PRASANNAGOUDA S PATIL 1BI20IS063
Mrs. ANUPAMA K C
ASSISTANT PROFESSOR
DEPT OF ISE , BIT
FACULTY INCHARGE:
SIGNALS , THE UNIX KERNEL SUPPORT FOR SIGNALS
UNIX PROGRAMMING - 18CS56
PRESENTATION ON

2. INTRODUCTION
 Signals are software versions of hardware interrupts.
 Every signal has a name. These names all begin with the three characters SIG.
 For example, SIGABRT is the abort signal that is generated when a process calls the
abort function.
 A parent & child process can send signals to each other for process synchronization.
 Signals are defined as positive integer flags in the <signal.h> header file.
 No signal has a signal number of 0. We'll see in further slides that the kill function
uses the signal number of 0 for a special case. POSIX.1 calls this value the null signal.
 FreeBSD 5.2.1, Mac OS X 10.3, and Linux 2.4.22 support 31 different signals,
whereas Solaris 9 supports 38 different signals.
 FreeBSD 5.2.1 and Mac OS X 10.3 define the signals in <sys/signal.h>.
 Linux 2.4.22 defines the signals in <bits/signum.h>, and Solaris 9 defines them in
<sys/iso/signal_iso.h>.

3. CONDITIONS THAT CAN GENERATE SIGNALS
 The terminal-generated signals occur when users press certain terminal keys. Pressing the DELETE
key on the terminal (or Control-C on many systems) normally causes the interrupt signal (SIGINT)
to be generated. This is how to stop a runaway program.
 Hardware exceptions generate signals: divide by 0, invalid memory reference, and the like. These
conditions are usually detected by the hardware, and the kernel is notified. The kernel then
generates the appropriate signal for the process that was running at the time the condition occurred.
For example, SIGSEGV is generated for a process that executes an invalid memory reference.

4.  The kill(2) function allows a process to send any signal to another process or process
group. Naturally, there are limitations: we have to be the owner of the process that
we're sending the signal to, or we have to be the superuser.
 The kill(1) command allows us to send signals to other processes. This program is just
an interface to the kill function. This command is often used to terminate a runaway
background process.
 Software conditions can generate signals when something happens about which the
process should be notified. These aren't hardware-generated conditions. Examples are
SIGURG (generated when out-of-band data arrives over a network connection),
SIGPIPE (generated when a process writes to a pipe after the reader of the pipe has
terminated)
Contd.

5. DISPOSITION OF THE SIGNAL
We can tell the kernel to do one of three things when a signal occurs. We call this the disposition of the
signal, or the action associated with a signal.
 Ignore the signal.
 This works for most signals, but two signals can never be ignored: SIGKILL and SIGSTOP.
 The reason these two signals can't be ignored is to provide the kernel and the superuser with a surefire
way of either killing or stopping any process.
 Also, if we ignore some of the signals that are generated by a hardware exception (such as illegal
memory reference or divide by 0), the behavior of the process is undefined.
 Let the default action apply.
 Every signal has a default action.
 Note that the default action for most signals is to terminate the process.

6.  Catch the signal.
 We tell the kernel to call a function of ours whenever the signal occurs.
 In our function, we can do whatever we want to handle the condition. If we're writing
a command interpreter, for example, when the user generates the interrupt signal at
the keyboard, we probably want to return to the main loop of the program,
terminating whatever command we were executing for the user.
 If the SIGCHLD signal is caught, it means that a child process has terminated, so the
signal-catching function can call waitpid to fetch the child's process ID and
termination status.
 As another example, if the process has created temporary files, we may want to write
a signal-catching function for the SIGTERM signal (the termination signal that is the
default signal sent by the kill command) to clean up the temporary files.
 Note that the two signals SIGKILL and SIGSTOP can't be caught.
Contd.

7. POSIX – Defined signals

8. Contd.

9. Contd.

10.  In Unix System V 3. cach entry in the kernel process table slot has an array of signal
Nags, one for each defined in the system
 When a signal is generated for a process, the kernel will set the corresponding signal
flag in the process table slot of the recipient process.
 If the recipient process is asleep (waiting a child to terminate or executing pause API)
the kernel will awaken the process by scheduling it.
 When the recipient process runs the kernel will check the process U-area that contains
an array of signal handling specifications, where each entry of the array corresponds to
a signal defined in the system.
 The kernel will consult the array to find out how the process will react to the pending
signal.
 If the array entry contains a zero value, the process will accept the default action of the
signal and the kernel will discard it.
The UNIX Kernal Support For Signals

11.  If the array entry contains a one value, the process will ignore the signal.
 Finally, if the array entry contains any other value, it is used as the function pointer for
a used defined signal hander routine.
 The kernel will setup the process to execute the function immediately, and the process
will return to its current point of execution (or to some other place if signal hander does
a long jump), if the signal hander does not terminate the process.
 If there are different signals pending on a process, the order in which they are sent to a
recipient process in undefined.
 If multiple instances of a signal are pending on a process, it is implementation -
dependent on whether a single instance or multiple instances of the signal will be
delivered to the process.
 In UNIX System V.3, each signal flag in a process table slot records only whether a
signal is pending, but not how many of them are present.
Contd.

12.  All Unix Systems and ANSI – C support the signal API, which can be used to define
the per-signal handling method.
 The function prototype of the signal is:
 signal_num is the signal identifier like SIGINT or SIGTERM defined in the <signal.h>
handler is the function pointer of a user defined signal handler function. This function
should take an integer formal argument and does not return any value.
 Example below attempts to catch the SIGTERM, ignores the SIGINT and accepts the
default action of the SIGSEGV signal.
Signals

13.  The SIG_IGN & SIG_DFL are manifest constants defined in <signal.h>
#define SIG_IGN void(*)(int) 1 //Ignore the signal
#define SIG_DFL void(*)(int) 0 //Default action7.
 The return value of signal API is the previous signal handler for the signal.
 The pause API suspends the calling process until it is interrupted by the signal and the
corresponding signal handler does a return.

14.  The sigset arguments and return value is the same as that of signal.
 Both the functions set signal handling methods for any named signal, but signal API is
unreliable and sigset is reliable.
 this means that when a signal is set to be caught by a signal handler via sigset when
multiple instances of the signal arrive one of them is handled while other instances are
blocked. Further the signal handler is not reset to SIG_DFT when it is invoked.
 UNIX system V.3 and V.4 support the sigset API, which has the same prototype and
similar use a signal.

15. Calculating letter frequencies

21. Archiving old files automatically

26. Extracting system hardware info.

33. Encryption and Decryption of files

35. Guessing a number

37. Questions with answers
1)