Process thread life and death

 

A Unix process is created when a process calls fork. Fork splits the running executable process into two parts. The sub-process will be allocated to the kernel stack. At the end of the stack, there is a thread_struct structure, which has a pointer pointing to the process descriptor task_struct. In addition, it is allocated an independent 4G address space. Of course, this is a virtual address space, represented by the mm_struct struct. There will also be members in the mm_struct struct indicating the physical address actually allocated. Based on the page missing mechanism, physical address spaces of the appropriate size will be allocated to the virtual address space as needed. There are other such variables as file descriptors. Then the process can be executed
A system call in the exec series replaces the currently running image with a new one.

When a parent process terminates before the child process, all its child processes are accepted by the init with PID 1. Init is a process that always calls the wait function. In this way, no zombie process will be generated. This is the case when designing the system init.

If the child process terminates before the parent process, a signal is sent to the parent process, and then the child process changes to the dead State until the signal is confirmed or the parent process is terminated. A detailed analysis of this situation is as follows:
Each process has a parent process. When a process exits, its exit status can be obtained by the parent process. After a process exits, many of its resources will be released. For example, if no other process is shared, it releases mm_struct, as well as the kernel stack and thread_struct. Only task_struct remains in the kernel and occupies the PID Number. The parent process calls the wait function to obtain the exit status information of the child process, read the process descriptor to obtain the exit status information, and delete the child process ID and the process descriptor from the system's progress table. The exit status information is stored in the kernel, occupying a small amount of memory space. If you do not call the wait function, the parent process cannot obtain the exit information of the child process. The child process ID is stored in the system process list all the time. Therefore, for the system, the sub-process is still an existing process, occupying an ID. In Linux, the number of processes is strictly limited. Therefore, when a sub-process exits, the ID is not deleted from the process list, which is a major risk of system security. If the wait function is not used, will the ID always exist? No. As long as its parent process is terminated, the child process ID will be deregistered along with the parent process. Note that termination means that the parent process is terminated. The parent process of the parent process can call functions such as wait to terminate the process, or the parent process of the parent process can terminate the process without calling the wait function. Because the sub-process exit information is stored in resources of the parent process, when the parent process exits, the space occupied by saving the sub-process exit information is also released.

Difference between fork and vfork:
(1) fork (): When fork () is used to create a sub-process, the sub-process only completely copies the resources of the parent process. In this way, the child process is independent of the parent process and has good concurrency.
Vfork (): When you use vfor to create a sub-process, the operating system does not completely copy the address space of the parent process to the sub-process. Instead, the child process shares the address space of the parent process, that is, the child process runs completely in the address space of the parent process. The sub-process modifies any data in the address space as seen by the parent process.
(2) fork (): The execution sequence of parent and child processes is not fixed;
Vfork (): ensure that the sub-process runs first and shares data with the parent process before exec or exit is called. Only after it calls exec or exit can the parent process be scheduled to run.
(3) vfork ensures that the sub-process runs first. After it calls exec or exit, the parent process can be scheduled to run. If the sub-process depends on the further action of the parent process before calling these two functions, a deadlock will occur.
(4) After a child process is created in vfork, the parent process becomes congested and the child process runs. After exit or exec is called, the child process replicates the parent process resource to its own address space. At this time, the parent-child process has the same relationship with the parent-child process created by fork. The parent process starts to run only at this time. Of course, sub-processes are always running.

The processor is always in one of the following states:
1. the kernel state runs in the process context. The kernel indicates that the process runs in the kernel space;
2. the kernel state runs in the interrupt context. The kernel indicates that the hardware runs in the kernel space;
3. User State, running in user space

The user space application enters the kernel space through the system call. At this time, the process in the user space needs to pass a lot of variables and parameter values to the kernel, and some register values and variables of the user process should also be stored during the kernel running. The so-called "process context" can be seen as the parameters passed to the kernel by the user process, as well as the entire set of variables and register values to be stored in the kernel and the environment at that time.

The hardware calls the interrupt handler through the trigger signal and enters the kernel space. In this process, some hardware variables and parameters must also be passed to the kernel. The kernel uses these parameters for interrupt processing. The so-called "interrupt context" can also be seen as the parameters passed by the hardware and other environments that the kernel needs to save (mainly the process environment currently interrupted ).

A section in the complete Linux comments:
When a process is executed, the values in all the registers of the CPU, the status of the process, and the content in the stack are called the context of the process. When the kernel needs to switch to another process, it needs to save all the statuses of the current process, that is, the context of the current process, so that when the process is re-executed, the status of the switch must be executed. In Linux, the current process context is stored in the task data structure of the process. In the event of interruption, the kernel executes the interrupt service routine in the kernel state in the context of the interrupted process. However, all required resources are retained to resume the execution of interrupted processes when the relay service ends.

Threads are similar to processes in the kernel. They can be called microprocesses. Based on the thread generation mechanism, it can be divided into kernel threads and user threads.

In addition, there is a test site where both threads and processes can be executed concurrently.

Reference http://blog.csdn.net/zhiyu520/archive/2008/07/27/2719827.aspx