Exit function of Process Control

The process has the following five normal termination methods:

(1) execute the return statement in the main function. This is equivalent to calling exit.

(2) Call the exit function. This function is defined by iso c. Its operations include calling each termination handler (The Terminator registers when calling the atexit function) and closing all standard I/O streams.

(3) Call the _ exit or _ Exit function. Iso c defines _ Exit, which aims to provide a method for a process to terminate without running a termination handler or signal handler. Whether the standard I/O Stream is rinsed depends on the implementation. In UNIX systems, _ Exit and _ exit are synonymous and do not clean standard I/O streams. The _ exit function is called by exit to process UNIX-specific details.

In most UNIX systems, exit (3) is a function in the Standard C library, while _ exit (2) is a system call.

(4) The last thread of the process executes the return statement in its startup routine. However, the return value of this thread is not used as the return value of the process. When the last thread returns from its startup routine, the process returns in the terminated state 0.

(5) The last thread of the process calls the pthread_exit function. In this case, the Process Termination state is always 0, which is irrelevant to the parameter sent to pthread_exit.

Three methods for terminating an exception are as follows:

(1) call abort. It generates the SIGABRT signal, which is a special case of Abnormal Termination.

(2) When a process receives certain signals. Signals can be generated by processes themselves (such as calling the abort function), other processes, or the kernel.

(3) The last thread responds to the cancellation request. By default, "cancel" occurs in a delayed manner: one thread needs to cancel another thread. After a period of time, the target thread terminates.

No matter how the process is terminated, the same piece of code in the kernel will be executed. This code disables all open descriptors for the corresponding process and releases the memory used by it.

For any of the above Termination cases, we all want the termination process to notify its parent process how it is terminated. For the three termination functions (exit, _ exit, and _ Exit), you can setExit status) Is passed to the function as a parameter. When an exception is terminated, the kernel (not the process itself) generates a reason to indicate the cause of the exception.Termination status). In any case, the parent process of the terminating process can use the wait or waitpid function to obtain its termination state.

Note: here we use the terms "exit status" (which is a parameter passed to exit or _ exit, or the return value of main) and "Terminate status" to indicate a difference. At the end of the call _ exit, the kernel will switch the exit state to the end state (recall figure 7-1http: // www.cnblogs.com/nufangrensheng/p/3507921.html ). If the child process is terminated normally, the parent process can get the exit status of the child process.

When describing the fork function, it is obvious that the child process is generated after the parent process calls fork. As mentioned above, the child process returns its termination status to the parent process. HoweverWhat if the parent process stops before the child process?The answer is: For all processes whose parent processes have been terminated, their parent processes are changed to init processes. We call these processes adopted by the init process. The operation process is roughly as follows: when a process is terminated, the kernel checks all active processes one by one to determine whether it is a child process that is about to terminate the process. If yes, the parent process ID of the process is changed to 1 (the ID of the init process ). This method ensures that each process has a parent process.

Another concern is thatIf a child process is terminated before the parent process, how can the parent process get the termination status of the child process during the corresponding check?The answer to this question is: the kernel stores a certain amount of information for each end-to-end sub-process. Therefore, this information can be obtained when the parent process that terminates the process calls wait or waitpid. This information includes at least the process ID, the termination status of the process, and the total CPU time used by the process. The kernel can release all the storage zones used by the terminating process and close all open files. In UNIX terms, a process that has been terminated but has not been processed by its parent process ( about the child process and release the resources it still occupies) is calledZombie). The ps (1) command prints the status of the zombie process to Z. If you write a program that runs for a long time and it calls fork to generate many sub-processes, unless the parent process is waiting to get the termination status of the sub-process, otherwise, the sub-processes will become zombie after termination.

The last question to consider is:What happens when a process adopted by the init process stops? Will it become a zombie process?The answer to this question is "no", because init is written to obtain its termination state whenever a sub-process is terminated. This prevents many zombie processes in the system. When "A init sub-process" is mentioned, it may be a process directly generated by init, or a process that has been terminated by its parent process and adopted by init.

 

This blog is excerpted from advanced programming for UNIX environments (version 2) and used only for personal learning records. For more information about this book, see:Http://www.apuebook.com/.