Extend Signals Section with more topics (#136)

courses/level102/system_calls_and_signals/signals.md

@@ -8,6 +8,51 @@ Signals are nothing but software interrupts that notifies a process that an even
 - catch the signal and handle them in a program-defined way
 - ignore the signal entirely
 
+## Signal Groups
+
+Signals fall into two broad categories. The first set constitutes the traditional or standard signals, which are used by the kernel to notify processes of events. On Linux, the standard signals are numbered from 1 to 31. The other set of signals consists of the realtime signals. Linux supports both POSIX reliable signals (hereinafter "standard signals") and POSIX real-time signals.
+
+### Realtime Signals
+
+Realtime signals were defined in POSIX.1b to remedy a number of limitations of standard signals. They have the following advantages over standard signals:
+
+- Realtime signals provide an increased range of signals that can be used for application-defined purposes. Only two standard signals are freely available for application-defined purposes: SIGUSR1 and SIGUSR2.
+- Realtime signals are queued. If multiple instances of a realtime signal are sent to a process, then the signal is delivered multiple times. By contrast, if we send further instances of a standard signal that is already pending for a process, that signal is delivered only once.
+- When sending a realtime signal, it is possible to specify data (an integer or pointer value) that accompanies the signal. The signal handler in the receiving
+process can retrieve this data.
+- The order of delivery of different realtime signals is guaranteed. If multiple different realtime signals are pending, then the lowest-numbered signal is delivered first. In other words, signals are prioritized, with lower-numbered signals having higher priority. When multiple signals of the same type are queued,
+they are delivered—along with their accompanying data—in the order in which they were sent.
+
+### Standard Signals
+
+The standard signals are the classical signals that have been there since the early days of Unix. Further here, we will be discussing about standard signals.
+
+## Signal Overview
+
+A signal is said to be generated by some event. Once generated, a signal is later delivered to a process, which then takes some action in response to the signal.
+Between the time it is generated and the time it is delivered, a signal is said to be pending.
+
+Normally, a pending signal is delivered to a process as soon as it is next scheduled to run, or immediately if the process is already running (e.g., if the process
+sent a signal to itself). Sometimes, however, we need to ensure that a segment of code is not interrupted by the delivery of a signal. To do this, we can add a signal to the process’s signal mask - a set of signals whose delivery is currently blocked. If a signal is generated while it is blocked, it remains pending until it is later unblocked (removed from the signal mask). Various system calls allow a process to add and remove signals from its signal mask.
+
+Upon delivery of a signal, a process carries out one of the following default actions, depending on the signal:
+
+- The signal is ignored; that is, it is discarded by the kernel and has no effect on the process. (The process never even knows that it occurred.)
+- The process is terminated (killed). This is sometimes referred to as abnormal process termination, as opposed to the normal process termination that occurs when a process terminates using exit().
+- A core dump file is generated, and the process is terminated. A core dump file contains an image of the virtual memory of the process, which can be loaded into a debugger in order to inspect the state of the process at the time that it terminated.
+- The process is stopped—execution of the process is suspended.
+- Execution of the process is resumed after previously being stopped. 
+
+Instead of accepting the default for a particular signal, a program can change the action that occurs when the signal is delivered. This is known as setting the disposition of the signal. To read more about disposition, refer [here](https://man7.org/linux/man-pages/man7/signal.7.html). A program can set one of the following dispositions for a signal:
+
+- The default action should occur. This is useful to undo an earlier change of the disposition of the signal to something other than its default.
+- The signal is ignored. This is useful for a signal whose default action would be to terminate the process.
+- A signal handler is executed.
+
+A signal handler is a function, written by the programmer, that performs appropriate tasks in response to the delivery of a signal. For example, the shell has a handler for the SIGINT signal (generated by the interrupt character, Control-C) that causes it to stop what it is currently doing and return control to the main input loop, so that the user is once more presented with the shell prompt. Notifying the kernel that a handler function should be invoked is usually referred to as installing or establishing a signal handler. When a signal handler is invoked in response to the delivery of a signal, we say that the signal has been handled or, synonymously, caught.
+
+Note that it isn’t possible to set the disposition of a signal to terminate or dump core (unless one of these is the default disposition of the signal). The nearest we can get to this is to install a handler for the signal that then calls either exit() or abort(). The abort() function generates a SIGABRT signal for the process, which causes it to dump core and terminate.
+
 ## Types of signals
 
 To list available signals in a Linux system, you can use the command `kill -l` . 
@@ -48,11 +93,12 @@ For example, the command `kill -9 367` sends SIGKILL to the process with PID 367
 - Sending signal to process via keyboard 
 
 Signals can be sent to a running process by pressing some specific keys.
-For example, holding Ctrl+C sends SIGINT to the process which kills it.
+For example, holding Ctrl+C sends SIGINT to the process which terminates it.
 
 - Sending signal to process via another process 
 
-A process can send a signal to another process via the kill() system call.
+A process can send a signal to another process via the kill() system call. In this use, signals can be employed as a synchronization technique, or even as a
+primitive form of interprocess communication (IPC). It is also possible for a process to send a signal to itself.
 `int  kill(pid_t pid, int sig)` system call takes 2 arguments, pid of the process you wish to send the signal to and the signal number of the desired signal.
 
 ## Handling signals
@@ -132,6 +178,8 @@ and returns the termination status of that child in the buffer pointed to by *st
 - Parent, on receipt of SIGCHLD , reaps the status of the child from the process table. Even though the child is terminated, there is an entry in the process table corresponding to the child where the process entry and PID is stored.
 - When the parent collects the status, this entry is deleted. Thus, all the traces of the child process are removed from the system.
 
+## Zombie and Orphane States
+
 If the parent decides not to wait for the child’s termination and it executes its subsequent task, or fails to read the exit status of the child, there remains an entry in the process table even after the termination of the child. This state of the child process is known as the Zombie state. In order to avoid long-lasting zombies, we need to have code that calls *wait()* after the child process is created. It is generally good to create a signal handler for the SIGCHLD signal, calling one of the wait-family functions in a loop, until no uncollected child data remains.
 
 A child process becomes orphaned, if its parent process terminates before the child .The orphaned child is adopted by init/systemd, the ancestor of all processes, whose process ID is 1. Further calls to fetch the parent pid of this process returns 1.