Process Control (Note for Apue and Csapp)

1. Introduction

We now turn to the process control provided by the UNIX System. This includes the creation for new processes, program execution, and process termination. We also look at the various IDs that is the property of the Process-real, effective, and saved; User and group Ids-and how they ' re affected by the process control primitives. Interpreter files and the system function are also covered. We conclude the chapter by looking on the process accounting provided by most UNIX systems. This lets us look at the process control functions from a different perspective.

Let's look at the process Control of UNIX systems together. Process Control includes the creation of new processes, program execution, and process termination. We will focus on the various IDs of the process properties, including the actual user ID (group ID), the valid user ID (group ID), the saved user ID and group ID, and how the IDs are affected by the process control primitives.

2. Process identification

Each process has a unique ID (non-negative integer) to identify.

There is some special processes, but the details of differ from implementation to implementation. Process ID 0 is usually the scheduler process and is often known as the swapper. No program on disk corresponds to this process, which are part of the kernel and is known as a system process. Process ID 1 is usually the INIT process and was invoked by the kernel at the end of the bootstrap procedure.

There are specialized processes in the system, and their specifics vary with implementation. A process with id 0 is usually a dispatch process, often referred to as a Swap process (swapper). The scheduling process is part of the kernel and exists as a system process, so there is no program on disk that corresponds to that process. A process with ID 1 is usually the init process, which is called by the kernel after the bootstrapper finishes.

The program file is the process Was/etc/init in older versions of the UNIX System and is/sbin/init in newer versions. This process is responsible for bringing up a UNIX system after the kernel have been bootstrapped. Init usually reads the system-dependent initialization files-the/etc/rc* files Or/etc/inittab and the files in/etc/in It.d-and brings the system to a certain state, such as multiuser.

The INIT process is responsible for booting a UNIX system after booting the kernel. Init typically reads system-related initialization files and directs the system to a state, such as multi-user.

The init process never dies. It is a normal user process, not a system process within the kernel, like the swapper, although it does run with Superuser privileges.

The INIT process will never terminate. It is a normal user process (unlike the swap process, the INIT process is not a system process in the kernel), but it runs with superuser privileges.

Note: In a computer system, the function of the CPU is to execute the program, that is: to refer to, decode, execute ... So, what happens to the CPU if there is no program to execute? At this point the CPU will execute the idle process, of course, the system process priority is the lowest.

In Linux Kernel,linux system, CPU is occupied by two kinds of programs: one is process (or thread), also called process context, the other is a variety of interrupts, exception handlers, also known as interrupt context.

The existence of a process is used to process transactions, such as reading user input and displaying it on the screen. There is always a time when the transaction is finished, as the user no longer enters, and no new content needs to be displayed on the screen. At this point the process can give up the CPU, but will be ready to come back (if the user suddenly has a button action). Similarly, if the system has no interrupts, abnormal events, the CPU will not take the time to interrupt the context.

In Linux kernel, the idle state of this CPU is called the idle state, and the Cpuidle framework is to manage this state.

In addition to the process ID, each process also has some additional identifiers, which look at the following functions:

Note that none of the above functions are returned in error.

3 Fork Function 1. Creating and terminating processes

From the programmer's point of view, we can assume that the process is always in one of the following three states:

1. Run. The process is either executed on the CPU or waiting to be executed and eventually dispatched by the kernel.

2. Stop. The execution of the process is suspended (suspend) and is not scheduled. When the Sigstop (corresponding event: not from the terminal stop signal), SIGTSTP (corresponding event: Stop signal from the terminal), Sigttin (corresponding event: Background process from terminal read) or Sigttou (corresponding event: Background process to the terminal) signal, the process is stopped, And keep stopping until it receives a sigcont signal, at this point, the process begins to run again (note that the signal is a form of software interruption).

3. Termination. The process stopped forever. Generally speaking, the process terminates for three reasons: 1) receives a signal that the default behavior is to terminate the process, 2) to return from the main program, 3) to call the Exit function.

2. Fork function

The parent process creates a new run child process through the fork function:

#include <unistd.h>
pid_t fork (void);
Return value: The child process returns 0, the parent process returns the child process ID, or 1 if an error occurs.

1) Call once and return two times:

The fork function is called once, but returns two times. The difference of two returns is that the return value of the child process is 0, and the return value of the parent process is the process ID of the new child process.

2) Concurrent Execution

The parent and child processes are independent processes that run concurrently. The kernel is able to alternately execute instructions in their logical control flow in any way.

3) The same but separate address space

The newly created child process is almost but not exactly the same as the parent process. A child process obtains a copy of the same but separate (mapped to different locations in memory) of the parent process's user-level virtual space address, including text, data, and BSS segments, heaps, and user stacks. The child process also obtains the same copy as any open file descriptor of the parent process, which means that when the parent process calls fork, the child process can read and write to any file that is open in the parent process. The biggest difference between a parent process and a newly created child process is that they have different process IDs.

Attention

It is worth mentioning that if standard I/O is used, the child process will also get a copy of the standard I/O buffers after the child process is fork (the standard library I/O buffers are usually allocated by malloc and therefore exist in the heap, and I/O buffers can be self-provisioned under Linux with Setvbuf).

4) Sharing files

All open file descriptors for the parent process are copied to the child process. It is said to be "copied" because each file descriptor is said to be executed as if it were a DUP function. The parent and child processes share a single file table entry for each of the same open descriptors, such as:

Therefore, if the file descriptor used is opened before the fork, then the parent and child processes will write to the file that the same descriptor points to, and if there is no form of synchronization, their output will be mixed with each other. A more common process is that after the fork, the parent and child processes each close the file descriptor they do not need to use, so that they do not interfere with the file descriptor used by the other party. This approach is often used by network service processes.

4. vfork function

1. Copy-on-write

Many implementations do not have a full copy of the data segments, stacks, and heaps of the parent process, since it is often followed by exec after fork. As an alternative, the write-time replication (Copy-on-write,cow) technique is used. These zones are shared by the parent and child processes, and the kernel changes their access rights to read-only. If any of the parent and child processes attempt to modify these zones, the kernel makes only one copy of the memory that modifies the zone, which is usually a "page" in the virtual memory.

2. Vfork

The Vfork function is used to create a new process, and the purpose of the new process is to exec a new program. Vfork creates a child process like fork, but Vfork does not copy the address space of the parent process into the child process. As mentioned earlier, implementation of write-time replication can improve the efficiency of the exec operations followed by fork, but it is faster to replicate than partial replication.

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. When a child process calls either of these functions, the parent process resumes running.

Attention

With Vfork, the child process runs in the address space of the parent process before the child process calls exec or exit, and therefore changes the parent process's variables.

2 Exit Functions

#include <stdlib.h>
void exit (int status);
void _exit (int status);
#include <unistd.h>
void _exit (int status);

5 Wait and Waitpid Functions

#include <sys/wait.h>
pid_t Wait (int *statloc);
pid_t waitpid (pid_t pid, int *statloc, int options);
Both return:process ID If OK, 0 (see later), or? 1 On Error

When a process terminates, whether it terminates gracefully or abnormally, the kernel notifies the parent process of the termination of the child process by sending a SIGCHLD signal to its parent process. Because the termination of a child process is an asynchronous event (which can occur at any time the parent process runs), this signal is an asynchronous notification of the kernel to the parent process. The parent process can choose to ignore this signal, or provide a function that is called when the signal arrives (signal processing function). The parent process ignores the signal by default. When a process calls wait or waitpid, the following conditions may occur:

1. If all the child processes of the process are still running, the parent process will block.

2. If a child process has terminated and waits for the parent process to get its terminating state, the parent process takes the child process's terminating state and returns immediately.

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

If a process calls wait because it receives a SIGCHLD signal, wait returns immediately. However, if you call wait at a random point in time, the process may block.

The differences between wait and Waitpid are as follows:

1. Wait blocks the calling process until a child process of the calling process terminates, and Waitpid has an option to prevent the calling process from blocking.

2. Waitpid allows the first terminated child process not to wait. It has several options to control the child process of the process wait.

If the child process is terminated and is a zombie process (that is, not yet reclaimed by the parent process), the wait function immediately returns and gets the state of the child process, otherwise the wait function blocks the calling process until one of the process's child processes terminates. If the calling process is blocked on the wait function and has more than one child process, wait is returned as soon as one of the child processes terminates. The calling process can distinguish which child process is terminated because the wait function returns the process ID of the child process being reclaimed.

For wait and waitpid, the parameter statloc is a pointer to an integer. If Statloc is not a null pointer, the terminating state of the child process is saved in the integer pointed to by the pointer. If the calling process does not care about the terminating state of the child process, you can set this parameter to a null pointer.

In general, the integer status returned by wait and waitpid is defined by the implementation, where some bits indicate the exit status (for normal return), some bits indicate the signal number (returned for exception), and a bit indicates whether the core file is generated, and so on. Posix.1 states that the termination status is viewed by each macro defined in <sys/wait.h>. There are 4 mutually exclusive macros that can be used to get the cause of the process termination, and their names are all in wif (wait If ...). Start As shown in the following:

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

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

2. pid > 0 Wait for the process ID to be equal to the PID child process.

3. PID = = 0 waits for any child process that belongs to the same process group as the calling process.

4. PID <–1 waits for any of the child processes in the specified process group (the absolute value of the PID ID)

The Waitpid function 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 Statloc. For wait, the only real error is that the calling process does not have a child process (another possibility is that the function call is interrupted by a signal that the error is returned). For waitpid, errors can occur if the specified process or process group does not exist, or if the process specified by the parameter PID is not the child process of the calling process.

The options parameter in Waitpid allows the calling process to further control the operation of the Waitpid. This parameter is either 0, or is the result of a bitwise OR operation of the constants shown.

Wcontinued: If the implementation supports job control, any child process specified by the PID resumes running after it has stopped, but the status has not yet been reported, WAITPID returns its state (POSIX xsi extension).

Wnohang: If the child process specified by the PID is not immediately available (not a zombie process), the calling process does not block on Waitpid, and its return value is 0.

wuntraced (Wait untraced): If support job control is implemented and any child process specified by the PID is already in a stopped state and its state has not been reported since it was stopped, WAITPID returns its state. The wifstopped macro determines whether the return value corresponds to a stopped child process.

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

1. Waitpid can Wait (recycle) a particular process, while wait returns the state of either terminating child process.

2. Waitpid provides a non-blocking version of wait. The calling process sometimes wants to get the state of a child process, but does not want to block.

3. Waitpid supports job control through the wuntraced and wcontinued options.

(not to be continued)

Process Control (Note for Apue and Csapp)