Eighth chapter: Process Control

8.1: Introduction

This chapter describes the process Control for UNIX, including creating new processes, executing programs, and terminating processes. It also describes the various id--of the process properties, the actual, valid, and saved user and group IDs, and how they are affected by the process control primitives. It also includes the interpreter file and the system function, and finally describes the process accounting mechanisms that are provided by most UNIX systems.

8.2: Process Identifier

Each process has a unique process ID that is represented by a nonnegative integer. Although it is unique, the process ID can be reused, and when a process terminates, its process ID can be used again. UNIX uses a deferred reuse algorithm to avoid the ID of the new process being equal to the ID of the recently terminated process.

In addition to the process ID, there are some other identifiers for each process. The following functions return these identifiers:

#include <unistd.h>pid_t getpid (void//  returns the process ID of the calling processpid_t getppid (void  //  Returns the parent process ID of the calling processuid_t getuid (void//  returns the actual user ID of the calling processuid_t Geteuid ( void // returns the valid user ID of the calling processgid_t getgid (void//  returns the actual group ID of the calling processgid_t getegid (void  //  Returns the valid group ID of the calling process

8.3:fork function

An existing process can call the fork function to create a new process:

#include <unistd.h>pid_t fork (void//  Create new process, return child process ID in parent process, return 0 in child process, less than 0, error

In general, whether the parent process runs first or the child processes after the fork depends on the scheduling algorithm of the system kernel. If a parent-child process is required to synchronize with one another, some form of interprocess communication is required.

One feature of fork is that all open file descriptors of the parent process are copied into the child process. Each of the same open descriptors for a parent-child process shares a file table entry. This way of sharing files makes the parent-child process use a file offset for the same file.

There are two common scenarios for working with file descriptors after fork:

1. The parent process waits for the child process to complete. In this case, the parent process does not need to do any processing of its descriptors. When the child process finishes, the file offset of any shared descriptor for which the read-write operation has been performed has been updated accordingly.

2. The parent-child process executes separate program segments. In this case, the parent-child process closes each file descriptor that they do not need to use, so that it does not interfere with the file descriptor used by the other party. This approach is often used in network service processes.

In addition to the file open descriptor, many other properties of the parent process are also inherited by the child process, including:

actual user ID, actual group ID, valid user ID, valid group ID, additional group ID process group ID session ID control terminal set User ID flag and set group ID flag current working directory root file mode create screened word signal masking and scheduling for any of the file descriptors is closed on execution (close -on-exec) flag shared storage segment resource limits for an environment connection

Differences between parent and child processes:

Fork return value Process ID is different for two processes with different parent process ID child processes Tms_utime, Tms_stime, Tms_cutime, and Tms_ Ustime are set to 0 the file lock that is set by the parent process is not set to empty when the unhandled alarm of the child process is cleared by the process that inherits the child process's non-processed alarms

There are two ways to use fork:

1. A parent process wants to replicate itself so that the parent-child process executes different pieces of code. This is the most common in a network service process-the parent process waits for the client's request to connect. When such a request arrives, the parent process calls fork to cause the child process to process the request, and the parent process continues to wait for the request to connect.

2. A process needs to implement a different program. This is a common scenario for the shell. In this case. The EXEC function is called immediately after the child process returns from the fork.

8.4:vfork function

The call sequence of the Vfork function is the same as the fork function, but the semantics are different.

Vfork is used to create a new process that is designed to exec a new program. Vfork creates a new process just like fork, but it does not completely copy the address space of the parent process into the child process, because the child process calls exec immediately and therefore does not access the address space. Instead, it runs in the space of the parent process before the child process calls exec or exit.

Another difference between vfork and fork is that vfork guarantees that the child process runs first, and the parent process may be scheduled to run after it calls exec or exit.

Since the vfork call, it executes in the parent process space before the child process calls exec or exit, so the child process's modifications to the variable affect the parent process.

8.5:exit function

As described in section 7.3, the process has the following 5 normal termination methods:

1. Execute the return statement within the main function, which is equivalent to calling the Exit function.

2. Call the Exit function. This function is defined by ISO C, which includes invoking each termination handler (the terminating handler is enlisted at the Atexit function) and then closing all standard IO streams.

3. Call the _exit function or the _exit function. ISO c defines _exit, which is intended to provide a way for a process to terminate without running a termination handler or signal handler. Whether the standard IO stream is flushed depends on the implementation. In Unix systems, _exit and _exit are synonymous and do not flush the standard IO stream. The _exit function is called by the Exit function, which handles UNIX-specific details. The _exit is defined by POSIX.

4. The last thread of the process executes the return statement in its startup routine. However, the return value of the process does not act as the return value of the process. When the last thread returns from its startup routine, the process is returned with a terminating state of 0.

5. The last thread of the process calls the Pthread_exit function. As before, in this case, the terminating state of the process is always 0.

Three kinds of abnormal termination methods are as follows:

1. Call the Abort function.

2. When the process receives certain signals.

3. The last thread corresponds to "Cancel".

Regardless of how the process terminates, the same piece of code in the kernel is executed at the end. This code closes all open file descriptors for the corresponding process, frees the memory it uses, and so on.

For any kind of termination scenario, we want the terminating process to be able to notify its parent process how it terminated. For three terminating functions (exit, _exit, _exit), this is accomplished by passing their exit state as a parameter to the function. In the case of an abnormal termination, the kernel (not the process itself) produces a terminating state (termination status) that indicates the cause of its abnormal termination. in either case, the parent process of the terminating process can use the wait or Waitpid function to get its terminating state.

Note that the "Exit status" (which is the argument passed to exit or _exit, or the return value of main) and the terminating state two terms are used here to indicate a difference. When the _exit is last called, the kernel transitions the exit state to the terminating state.

In UNIX terminology, a process that has been terminated but whose parent process has not yet processed it is called a zombie process.

8.6:wait and Waitpid functions

When a process is normal or abnormally terminated, the kernel sends a SIGCHLD signal to its parent process. Because the child process termination is an asynchronous event (which can occur at any time the parent process runs), this signal is also an asynchronous notification that the kernel sends to the parent process.

What can happen when you call wait or Waitpid are:

1. Block if all of its child processes are still running.

2. If an I-child process has been terminated and is waiting for the parent process to get its terminating state, it gets the terminating state of the process and returns immediately.

3. If it does not have any child processes, an immediate error is returned.

#include <unistd.h>pid_t wait (int *intint options); Waits for the specified child process to terminate

The differences between the two processes are as follows:

1. Before a process terminates, wait causes its callers to block, and Waitpid has an option that allows the caller to not block.

2.waitpid does not wait for the first terminating child process after its invocation, it has several options to control the process it waits for.

The integer pointer staloc is used to get the terminating state, which can be empty if the terminating state is not concerned.

The function of the PID parameter in the Waitpid function is interpreted as follows:

PID = =-1 waits for any child process. In this respect, Waitpid is equivalent to wait.

PID > 0 Wait for its process ID to be the same as the PID of the child process

PID = = 0 waits for its group ID equal to any child process that invokes the process group ID.

PID <-1 waits for any child process whose group ID equals the absolute value of the PID.

Waitpid returns the process ID of the terminating child process and stores the terminating state of the child process in the storage unit pointed to by Staloc. For wait, the only error is that the calling process has no child processes.

The options constants in the Waitpid function

wcontinued if job control is implemented, any child process specified by the PID will continue after the pause, but its status is not yet reported, and its status is returned.

Wnohang If the child process specified by the PID is not immediately available, the waitpid is not blocked, and its return value is 0

wuntraced If an implementation supports job control, and any child process specified by the PID is already paused and its state has not been reported since it was paused, its state is returned.

The Waitpid function provides three features that the wait function does not provide:

1.waitpid can wait for a specific process, while wait returns the state of either terminating child process.

2.waitpid provides a non-blocking version of the wait function.

3.WAITPID provides job control.

Instance:

If a process fork a child process, but do not wait for the child process to terminate, nor want the child process to be in a zombie state until the parent process terminates, the trick to implement this requirement is to call fork two times. The procedure is as follows:

8.7:waitid function

Eighth chapter: Process Control