Hello and welcome!
In this video session we will begin a new topic on signals.
Signals are like the interrupts that occur when the program is running.
These interrupts are asynchronous events.
This means we are not sure when the interrupt occurs when the program is running.
So a synchronous events are those in which we know the occurrence of the events, but asynchronous events
are those in which the user or the program is not aware of the events timings in which they occur.
So these are asynchronous events are called as like a software interrupts.
So these signals can originate from outside the system as well as within the system.
The example in which it can in which the signal can generate outside the system is.
Let's say we are running a program.
And when the user enters a sequence of characters from the keyboard like Ctrl C, then we are in fact
sending a signal to the process.
So this is an example of a signal that is being generated from outside the system.
In the same way, within the system, also the kernel generates the signals and processes it to the
desired process, so the signals are identified by a unique number in Linux systems, and each signals
has their own way of handling the signal.
So a signal has a very precise life cycle.
The signal is raised first.
The kernel stores the signal, and at appropriate time it delivers to the required process.
The process once it receives the signal, it handles accordingly.
There are different actions that can be taken by the process for each of the signals, so all the signal
by default has a default action.
Let's see more on this.
So a kernel can perform one of the three actions depending on what the process is asked to do.
Example.
The process can ignore the signal.
That is, it can.
The process can behave as if the signal has not occurred at all.
But there are two signals that cannot be ignored.
They are sigkill and sigstop, so these signals cannot be ignored.
Then next the process can catch the signal and handle the signal accordingly.
So whenever the process gets the signal, the There is a handler written for each signals, so whenever
the signal has an dedicated handler, handler is nothing but a function that will be called when the
signal arises.
So if a particular signal handler is present, the execution jumps to that handler and executes the
code that is given in the handler then returns back to the main program.
Let's see this for more examples in the next slide.
Then we have one more action that is performing the default action.
So performing the default action means whenever a signal comes to the process.
And if there are no signal handlers then by default every signal has a default action to be performed.
So this is the three different ways in which the process can look at the signal.
The first one is like ignoring the signal.
The process can either ignore the signal or handle the signal, or perform the default actions.
So all these three things is controlled by the code.
Now let us see how a signal handler works if a signal is being handled.
So let us see this case.
That is we we are writing a separate signal handler for a specific signal.
So in this case we can see that we have a main program running.
And these are the different instructions that are running.
And we have a dedicated signal handler.
So by signal handler we mean that there is a dedicated function that will be called.
And it has a code instructions inside that.
So let us say that the main program is running and the signal can occur at any time.
That is why we call it as a asynchronous event and when the signal is delivered to the process from
the kernel.
The current instruction will be executed, and then it jumps to the signal handler, and then it executes
the signal handler code and returns back to the main program.
So this is the general life cycle of a signal handler.
A signal is being identified and it has a prefix of sig.
So all the signals has a prefix of sig.
For example, a signal Sigint has a prefix of sig and this is raised.
Sigint is raised usually when the user presses a control and C on the keyboard, and all the list of
signals is been defined in a header file called as signal dot h.
Now let's have a look into the signal list from.
This diagram is taken from the signal dot h header file.
Here you can see the.
Each signal has a unique number.
For example, Hup is assigned the number one.
Sigint is assigned the number two, and it goes on.
So each signal has a unique number and it can be identified either.
So for example either the user code can call it as a sigterm or using the number one five.
So both are interchangeably used.
So as we have discussed in the previous slides that every signal has a default action.
For example, we have shown here that the signals will have a default action.
That means if a signal does not have a signal handler written separately, then by default it has a
action to be taken.
So these are the list of signals on the left hand side, and the default actions of every signals on
the right hand side.
So for example a group will have a default action to terminate the current process In the same way,
it will have a default action to terminate the process before terminating it.
It generates a condom and then terminates so that the user can read the condom file in order to understand
why the termination occurred.
So these are the different signals and its default actions.
So in this list of signal handlers, just for understanding purpose, let's take few of the signals
which are more commonly used.
And let's discuss few of the signals.
We will not be going through all the signals, only the few signals we will take as an example.
And let's discuss it.
So sig abort is a signal that has been raised when a abort function is being called.
So whenever a abort function is called in a process, the process receives a signal called sig abort,
and in this case a code file is being generated and the process terminates.
So as a result of this, the code dump file can be used by the user to debug why the process had terminated.
SIG alarm sig alarm is a signal that is generated when the alarm function is called, and the timer
that is used inside the alarm expires and and the signal sig alarm is called.
We can see some examples of alarm down the line.
Sigbus also called as the bus error, so this signal is raised when the process has a memory access
related error.
When memory access error occurs, this sigbus is called and we had discussed the Sigchld when we had
done the parent and child process.
So whenever a child process terminates, a sick child is being raised and delivered to the parent process.
Sick.
Continue.
Whenever the Colonel wants a process which is stopped to resume, then the Colonel sends a signal called
as sick.
Continue in order to continue the stopped process and the process will be resumed.
Sick.
PHP.
PHP is a signal raised in case of a arithmetic execution.
Exception occurs and there are different similar process.
Signal is.
Whenever a illegal machine instruction is executed, signal is generated, and Sigint is generated.
When user presses control C and signal is sent from the kill system call.
So we have different signal sizes.
Sigpipe is used.
Uh, this is a signal occurred when we have a pipe related operation.
So we will see sigpipe down the line when we discuss about pipes.
So a signal has two types of, uh, user provided signal sig user one and sig user two.
These two signals are the signals which are user defined.
Purpose.
So user can generate these signals for user applications.
So user can send from one process to other process these signals.
And uh so these signals are not raised by the kernel and user raises this signals.
So what we have discussed is only a few uh subset of the signal.
You can go through a list of all the different signals in order to understand the each signals in depth.
So, uh, in next session video session, we will be having a look into the code part of the signal
and how to handle the signal handlers.
What are the default actions.
And all this we will be seeing using the code examples.