The above code looks very simple, the descendants of the fork is, basically in line with our general conjecture, logically correct, but to say: Why the same code when the output will be different? After the completion of the execution of the/fork is normal back to the shell, But there's no return to the shell on the right, so why? This and the fork's nature "after fork is not sure which process is the first to perform the correlation" the left side of the situation is: After the last process 4742 execution, the parent process is still not finished. Then the parent process ends, returning to the parent process's parent process, which is the shell to the right: before the output [email protected] and so on, the parent process has finished exiting, so the back of the child process will not return to the shell after execution, but will return to his parent process, do not know who is it, It's not going to be the shell, so it's going to cause the phenomenon shown in the diagramthe above-mentioned content is not to say the key content, is a personal understanding, not necessarily right, please correct me! Here is a look at the implementation of the modified code, and we are at first glance at the procedural conjecture or understanding of the inconsistency.
The same code simply removes the last ' \ n ' line break from the printed statement, and the effect is really quite different: 16 statements printed!!! What is this for? Look at the contents of the printed statement: The first one is definitely the initial process of printing, this will not be questioned, then his PID is 4772, you can see, this 4772 was printed 9 times the remaining 7 is the fork after the process of the process PID why will print 9? Originally this and fork of the second property is related to the "fork after the child process will replicate the parent process's resources, the buffer is the parent process's resources, so it will naturally replicate a copy" so it is understood that the initial process has 7 descendants of the process, so all copy a first buffer, At the end of itself, exit flushes the buffer, which includes the buffer that copies the parent process and its own PID content that it needs to print. The original process itself is printed two times (first and last) so the 2+7*2-=16 bar is printed, where 4772 prints the 2+7=9 bar
Since this is the case (the child process replicates the buffer of the parent process), why did the experiment with ' \ n ' in the previous print statement be "correct"? This is determined by the different buffering properties for the device. Our reality is that the device that runs the result is a standard output device, and the standard output device is normally a line cache device in Linux (except for an error) "\ n" is just a newline character, so the cache is emptied when swapping rows. "writes to the file stream in Linux is fully cached, that is, the newline character does not flush the buffer" What do we do to output the results to a file?
As you can see, the output without ' \ n ', except the shell prompt, analysis is the same but with the ' \ n ' output to the file, it becomes fully buffered, so it will naturally output 16 statements
Presumably after this experiment, we can have a perceptual understanding of the characteristics of fork and the characteristics of the equipment ....
Linux kernel source Learning fork Buffer
