Windows system >> Linux system Tutorial >> Linux Tutorial

Linux Process Fundamentals Summary The

process represents a running instance of a program that is the smallest unit of allocated resources. This statement is particularly official.
The process is a very important thing. We run a system that runs N processes at the same time. These processes are working silently. The code we write, after compiling and running, will also generate a process. This process consists of program code, data, variables (occupying system memory), open files (file descriptors), and the environment. In general, for Linux systems, the system shares program code and system function libraries between processes, so at any time, there is only one copy of the code in memory.
Because the process is so important, this article gives a basic summary of the processes in Linux.
Create a process
The story begins with creating a process. Take a look at the following code:
#include <stdio.h>#include <unistd.h>#include <stdlib.h>int main(){ pid_t pid; char *msg; int n; printf( "Fork program starting\ "); pid = fork(); //Create a process //After the creation is complete, both the parent and child processes start running switch (pid) { case -1: perror("Fork Failed."); exit(EXIT_FAILURE); case 0: //When the fork returns a value of 0, it means that this is the child process msg = "This is the child"; n = 2; break; default: //If fork is not 0 and -1, it means that this is the parent process msg = "This is the parent"; n = 3; break; } for (; n > 0; --n) { printf("%s \ ", msg); sleep(1); } exit(EXIT_SUCCESS);}We use the fork function to create a child process. The declaration of the fork function is as follows:
#include <unistd.h>pid_t fork(void) ;fork function Pid_t a type of value, pid_t type is a type int. After the fork creation process is successfully executed, both the child process and the parent process start running from the code after the fork function. So since they all start from the same place, how do you distinguish between a child process or a parent process?
Linux uses the return value of fork to distinguish, as follows:

When fork returns pid_t value of -1, it means that the creation process has an error;

When fork returns a value of pid_t of 0, it means that it is a child process;

When fork returns the value of pid_t is not 0 and -1, it means the parent process.

In the above code, I just judge whether it is a child process or a parent process based on the return value of fork. How do you feel strange?
The structure of the process
Once again, the process is very important, we need to understand, then the structure of the process has to be said. So after we create a process using fork, what is the structure of the process inside the memory? Let's take a look.

As shown in the above figure, we did not consider the contents mentioned in the figure when actually coding, but the things shown in the above figure are the key to understanding the parent process and the child process. Regarding many problems of the process, we also think about starting from the above diagram. Later, I will specifically ask a few questions to analyze why the process memory image is so important.
Process scheduling
On a single processor, only one process can run at a time, and other processes are waiting to run. However, our actual feeling is that there are multiple processes at the same time at the same time & rdquo; running, why is this?
Operating system
will give each process a certain running time, called &# time slice”. The process runs in this "time slice", because the "time slice" is very short, which gives the illusion that multiple programs are running at the same time. How does the operating system
schedule the process? There are many rules for process scheduling, such as scheduling algorithms based on priority, FIFO scheduling algorithms, and so on.
The Linux kernel process scheduler schedules processes based on the priority of the process. Processes with higher priority run more frequently.
Process Status
There are five states on Linux:

Running (running or waiting in the run queue)

Interrupt (sleep, blocked, waiting for some Condition formation or reception of signals)

Uninterruptible (received signals are not awake and not operational, processes must wait until an interrupt occurs)

Zombie (process terminated, but process descriptor Exist, until the parent process calls wait4() after the system call is released)

Stop (the process stops after the SIGSTOP, SIGSTP, SIGTIN, SIGTOU signals are received)

When we use the ps -aux command What do the letters that identify the process mean when looking at the process state? The character identifier of the specific process state is shown in the following table:

state flag
state description
D non-interruptible R run S interrupt T stop Z zombie
but Sometimes, we will see some other identifiers, for example:

state flags
state description
W zombie< high priority process N low priority Level process L memory lock page
See above is interrupted, can not be interrupted, stop, zombie, directly dizzy, then how to understand these concepts?

Running state In Linux, processes that wait only for CPU time are called ready processes. They are placed in a run queue. The status flag of a ready process is TASK_RUNNING. Once a running process time slice is exhausted, the Linux kernel's scheduler will deprive the process of control of the CPU and select a suitable process from the run queue to put it into operation.

Linux sleep sleep in the process, there are two:

One is interruptible sleep state, its state flag TASK_INTERRUPTIBLE;

The other is an uninterruptible sleep state with a status flag of TASK_UNINTERRUPTIBLE. An interruptible sleep state process sleeps until a condition becomes true. For example, generating a hardware interrupt, releasing system resources that the process is waiting for, or passing a signal can be a condition for waking up the process. The uninterruptible sleep state is similar to the interruptible sleep state, but with one exception, the process of passing a signal to this sleep state cannot change its state, that is, it does not respond to wake-up of the signal. Non-interruptible sleep states are generally less useful, but they are useful in some specific situations. For example, a process must wait and cannot be interrupted until a particular event occurs.

When a SIGSTOP signal is sent to the process, it enters the TASK_STOPPED state in response to the signal (unless the process itself is in the TASK_UNINTERRUPTIBLE state and does not respond to the signal). (SIGSTOP, like the SIGKILL signal, is very mandatory. The user process is not allowed to reset the corresponding signal handler function via the system call of the signal series.) Sending a SIGCONT signal to the process allows it to return from the TASK_STOPPED state to the TASK_RUNNING state.

zombie state process in the process of withdrawal, the state in TASK_DEAD. During this exit process, all resources owned by the process will be reclaimed, except for the task_struct structure (and a few resources). So the process is left with only a skeleton of task_struct, so it is called a zombie. The task_struct is reserved because the task_struct stores the exit code of the process and some statistics. And its parent process is likely to care about this information. For example, in the shell, the $? variable saves the exit code of the last exiting foreground process, and this exit code is often used as a condition for the if statement. Of course, the kernel can also save this information somewhere else, and release the task_struct structure to save some space. But using the task_struct structure is more convenient, because the pid to task_struct lookup relationship has been established in the kernel, as well as the parent-child relationship between processes. To release the task_struct, you need to create some new data structure so that the parent process can find the exit information of its child process.

The parent process can wait for the exit of one or some child processes through the system calls of the wait series (such as wait4, waitid), and get its exit information. Then the system call of the wait series will release the child process's corpse (task_struct).

In the process of exiting the child process, the kernel will send a signal to its parent process to inform the parent process to "collect the corpse". This signal defaults to SIGCHLD, but this signal can be set when a child process is created via the clone system call.

The following code can be used to create an EXIT_ZOMBIE state process:
if (fork()) while(1) sleep(100);

With ps -aux you will see the following zombie Process information.

As long as the parent process does not exit, the child process of this zombie state will always exist. Then if the parent process quits, who will come to the child process & ldquo; corpse & rdquo;?

When a process exits, it will host all its child processes to other processes (making it a child of another process). Who is it for? It may be the next process (if it exists) of the process group in which the process is exiting, or the process No. 1. So every process, every moment, there is a parent process. Unless it is the number 1 process.