Answer: The reason why the sub-process runs first after the fork () function is executed.

Friends who have written fork () functions should have experience. Generally, after using the fork () function, the subprocess is always executed first when printing the execution sequence. But the book says that the execution sequence between the sub-process of the fork function and the parent process is uncertain. Why?

This involves a kernel technology: Copy-on-write, that is, copy when writing. The traditional fork function call directly copies all resources to the newly created process, which is simple but a waste! The copy-on-write technique is a technique that delays or does not copy data when a new process is created. After a new process is created, the kernel does not copy the address space of the entire process to the sub-process. Instead, it allows the Parent and Child processes to temporarily share an address space. Only when the sub-process needs to write data, data is copied to the sub-process address space. For example, if you call exec () immediately after fork (), you do not need to copy the data of the entire address space. Fork () the overhead is limited to copying the parent process's page table and creating a unique process descriptor for the child process.

The newly created process always calls exec (). Therefore, the kernel usually runs the newly created sub-process first. But it is not absolute.

In my personal understanding, it is not suitable for anyone.