A brief analysis of Linux fork function

#include <sys/types.h> #include <unistd.h>/* features: Replication process parameters: No return Value: Success: Parent process: Return child process ID subprocess: return 0 Failure: Returns -1*/pid_t fork (void);

A new process created by Fork is called a subprocess (child process). The 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 process (child process). The reason for returning the child process ID to the parent process is that because there are more than one child process in a process, there is no function that enables a process to obtain the process ID of all its child processes. For a sub-process, fork returns 0 to it because it can call Getpid () to get its own PID at any time, or it can call Getppid () to get the ID of the parent process. (Process ID 0 is always used by the interchange process, so the process ID of a child process cannot be 0).

After fork, the operating system replicates a child process that is exactly the same as the parent process, although it is a parent-child relationship, but in the operating system it appears that they are more like siblings, that the 2 processes share the code space, but that the data space is independent, and that the content in the child process data space is a complete copy of the parent process. The instruction pointer is also exactly the same, where the child process has the current execution of the parent process (the two process's program counter PC value is the same, that is, the child process starts at the fork return), but a little different, assuming that fork succeeds, the return value of fork in the child process is 0, The return value of the fork in the parent process is the process number of the child process, assuming that the fork is unsuccessful and the parent process returns an error.
It can be imagined that 2 processes have been executed at the same time, and that, after the fork, they were doing different jobs, that is, unison. That's why fork is called fork.

As for the first implementation, it may be related to the operating system (scheduling algorithm), and this problem is not important in practical applications, assuming that the parent-child process is coordinated, can be resolved through the primitive language approach.

A fork Example

#include <unistd.h> #include <sys/types.h> #include <stdio.h>int main (void) {pid_t pid;pid=fork (); Switch (PID) {case-1:perror ("fork Error"); exit (1); case 0:printf ("I am the child process, my process ID is%d/n", Getpid ()) ; break;default:printf ("I am the parent process, my process ID is%d/n", getpid ()); return 0;}

To understand the fork's running process, you must first understand the "process" concept in the operating system. A process, consisting mainly of three elements:
O. A program capable of running;
O. All data associated with the process (including variables, memory space, buffers, etc.);
O. The running context of the program (execution context).

It is better to simply understand that a process represents a state in a running process that can run a program. The management of the process by the operating system, typically through the process table. Each table item in the process table, which records the condition of a process in the current operating system. In the case of a single CPU, only one process consumes the CPU at a given time, but there may be multiple active (waiting or running) processes in the system at the same time.
A register called "program counter, PC," which indicates the location of the next instruction to be run by the current CPU-consuming process.
When the CPU time allocated to a process is exhausted, the operating system saves the value of the register associated with the process to the corresponding table entry in the process table; The context of the process that will take over the CPU of the process, read from the process table, and update the corresponding register (this process is called "Context Exchange" ( Process context Switch) ", the actual contextual exchange needs to involve a lot of other data, which is not related to fork, no longer say, the main thing to remember is that the program register PC record where the program is currently running, is the process context of important content, swap out CPU process to save the value of this register, the process of swapping into the CPU, but also according to the process table saved in the process run context information, update this register.
Well, there are these concepts that can be said to be fork-bottom. When your program runs to the following statement: Pid=fork ();

The operating system creates a new process (child process) and corresponds to a new table entry for it in the process table. The new process and the original process of the running program is the same program, context and data, the vast majority of the original process (parent process) copy, but they are two independent processes! At this point the program register PC, in the context of the parent and child processes, claims that the process is now running to the fork call is about to return (at this point the child process does not occupy the CPU, the child process's PC is not really saved in the register, but is saved as the process context in the corresponding table key in the process table). The question is how to go back and split up in the parent-child process.

(If the parent process has been occupying the CPU, it is very likely that it will be different) the parent process continues to run, and the implementation of the fork in the operating system causes the call to return the PID (a positive integer) of the child process just created in the parent process, so the following Swtich statement runs the default branch (case -1,case 0 Branches are not satisfied). So output I am the parent process ...

The child process is dispatched at some later time, its context is swapped in, the CPU is occupied, the operating system implements the fork, and the fork call in the sub-process returns 0, so in this process (note that this is not the parent process, although it is the same program, but this is another run of the same program, In the operating system this run is represented by another process, pid=0 from the point of view of running and the parent process being independent of each other. While this process continues to run, the case-1 in the switch statement is not satisfied, but case 0 is satisfied. So output I am the child process.

The execution result of the program (first output I am the parent process ..., or I am the parent process ...). Unforeseen, related to the actual implementation of the operating system!