It seems that Fork () is very simple. You can generate new processes, let them handle different parts of the problem parallel. Of course, if these processes are not communicated with each other and just do their own things is the easiest. In UNIX systems, the only way to create a new process is to call the system call. The process of calling fork is called a parent process, and the newly created process is called a child process. The syntax format of the system call: PID = fork (); When returning from the system calling fork, the two processes have except for the return value PID, with an exact same user-level context. In the child process, the value of the PID is zero. Process 0 created by the core within the core when the system starts, is the only process created by the system calling fork. The core is called for the system to complete the following: assign an empty item in the process table for the new process. Assign a unique process identification number (PID) for the child process. Make a logical copy of a parent process context. Due to certain parts of the process, such as the body area, it may be shared by a few processes, so the core sometimes adds the number of references to a certain area, rather than really copying the area to a new memory physical area. Increase the number of file tables and index node tables associated with the process. The process number of the parent process returns the sub-process, returns zero the child process. Understanding the implementation of the system calling fork is important because the child process starts its execution sequence as far as the sky is descending. Below is an algorithm for the system calling fork. The core is first confident that there is enough resources to successfully complete the Fork. If the resource is not satisfied, the system calls fork failed. If the resource meets the requirements, the core finds an empty item in the process table and starts the context of the sub-process. Algorithm: fork input: No output: Parent process is the PID pair of child processes is 0 {Check available core resources to take an idle process entry and the only PID number Check the user does not have too much running process will be sub-process Status Set to "Create" Status Copy the data in the process table of the parent process to the index node of the child process table and the changed reference number of the changed root (if possible) plus 1 file table in the file table. Number 1 Press the copy of the child process context in memory in the system-level context in the sub-process, pressed into the dummy system-level context layer / * The virtual context layer contains the enabled sub-process * to identify its own data, and make the sub-process scheduled * From here, running * / if (the process being executed is the parent process) {Set the status of the child process to "Ready" status Return // From the system to the user} else} Else {Initialization timing zone Return RETURN 0;}} Let's take a look at the example below. The program illustrates the shared access of the file after the system calls fork. When the user calls the program, there should be two parameters, one is the already file name, and the other is the new file name to be created. This process opens existing files, create a new file, then assume that there is no incorrect error, which calls fork to create a child process. The sub-process can inherit the file (i.e., the parent process has opened and created) by using the same file descriptor. Of course, the parent process and sub-process should independently call the RDWRT function, and execute a loop, read one byte from the source file, and then write one byte to the target file. When the system calls the READ, the function RDWRT returns immediately. #include
INTFDRD, FDWT; Charc; Main (int Argc, char * argv []) {if (argc! = 3) {EXIT (1);} if ((fdrd = open (argv [1], o_rdonly) == - 1) {EXIT (1);} if ((fdwt = creat (argv [2], 0666)) == -1) {EXIT (1);} fork (); // Two processes Perform the same code RDWRT (); exit (0);} RDWRT () {for (;;) {IF (Read (FDRD, & C, 1)! = 1) {Return;} Write (fdwt, & c, 1);}} In the example, the file descriptors of the two processes points to the same file entry. These two processes will never read or write the same file offset, because the core is increased to increase the offset of the file after each Read and Write calls. Although two processes seem to copy the source file twice, because they share the task of work, the content of the target file depends on the order of the two processes in the core. If the core is scheduled two processes: Make them alternately execute their system calls, or to make them alternately execute each pair read and write calls, the content of the target file is exactly the content of the target file. However, consider such a situation: two processes are about two consecutive characters "ab" in the source file. If the parent process reads the characters "a", at this time, the core has made a context switch to perform sub-process before writing. If the child process is read to the character "B" and writes it to the target file before the parent process is scheduled, the target file will no longer contain the string "ab", but "Ba" is included. The core does not guarantee the relative rate of the process. Let's take another example: #include
