Fork () function--parent-child process resource question

Fork () function function--Create a new process

1. The parent-child process has separate data segments, heaps, stacks, shared code segments

Each process in Linux has a 4G virtual address space (separate 3G user space and shared 1G kernel space), and the sub-process created by fork () is no exception. The origin of the child process resources:

1.1G kernel space since it is shared by all processes, the child processes created by fork () will naturally also be owned;

2.3G of user space is from the parent process process.

Fork () When you create a child process, you inherit the data segment, code snippet, stack segment, heap of the parent process, Notice that the virtual address space is inherited from the parent process, and that the page table is copied (no physical blocks are copied). Therefore, the parent-child process has the same virtual address at this point, and the mapped physical memory is also consistent (a separate virtual address space that shares the parent process's physical memory).

Because the parent and child processes share physical pages, the kernel marks them as "read-only" (like Mmap) private, and neither parent nor child can modify them. Regardless of when the parent and child processes attempt to write to a shared page, an error occurs when the kernel copies the page to a new page to the process, marks it as writable, modifies the page table, marks the original read-only page as "writable", and leaves it for another process to use-- Write-time replication technology.

Note: When the kernel allocates physical memory for a child process, it does not copy the data corresponding to the code snippet to the child process, and the parent-child Process code snippet maps the same piece of physical memory (the code snippet is inherently read-only within a single process).

The virtual address space for each process can be 0 to 4G, except that only a subset of them have access, and each process can have a different mapping. Two runs the same program is the same virtual address used, but the mapping to the physical is not the same. Each process has its own virtual address space, and the same virtual address for different processes can obviously correspond to a different physical address. So the same address (virtual address) and the value of the difference is no surprise.

Copy-on-write techniques see: http://www.cnblogs.com/wuchanming/p/4495479.html

2. Call two executions at a time

See also: http://blog.csdn.net/shenwansangz/article/details/39184789

3. Competitive conditions

Linux is a multi-user operating system, at the same time there will be many users competing for system resources. Sometimes processes create child processes to compete for resources in order to complete tasks earlier. Once a child process is created, the parent-child process continues to execute from the fork, competing for the resources of the system. Sometimes we want the child process to continue, and the parent process blocks until the child process finishes the task. At this point we can call wait or waitpid system call.

In the case of a sub-process, the fork returns to 0, but its PID is definitely not 0, and the fork returns 0 to it because it can call Getpid () at any time to get its own pid;fork. The parent-child process will not be able to determine who runs first unless synchronous means is used. I'm not sure who will end first. It is not right to think that the child process is over stepfather process is returned from fork, which is not the case with fork, vfork.

4. Follow the exec after fork

Fork () produces a child process that is exactly the same as the parent process, but the child process will then exec the system call, and for efficiency reasons, Linux introduces a "copy-on-write" technique that copies the contents of the parent process to a child process only if the contents of each segment of the process space are to change. Because of copy-on-write, before the fork exec two processes have separate virtual address space, sharing physical memory. The data segment, stack, and heap of the child process are allocated physical space only if one of them needs write operations. However, when exec is called on a child process, it empties the stack, heap, and space shared with the parent process, reloading the new code snippet, thus avoiding the chance of copy-on-write copies of the shared page, and the parent process has the original shared physical memory (which can read and write to it).

Fork out the child process, the parent-child process which first scheduling directly determines whether the need to copy the problem? The kernel typically dispatches child processes first, because in many cases the process is to execute EXEC immediately and avoid useless replication. If the parent process first dispatches the most likely to write a shared page, it produces "copy-on-write" without effort. Therefore, the child process is usually the first to dispatch drops.

On the internet there is a detail problem is that after fork the kernel will be placed in front of the queue, so that the child process first, so that the parent process will not cause the execution of the copy, and then the child process exec system calls, because of meaningless replication resulting in a decrease in efficiency.

If it is not for exec, the child process is likely to modify memory when it executes, the kernel assigns the corresponding physical space to the child process's data segment, the stack segment (at which point the two have their own process space, which does not affect each other), and the code snippet continues to share the physical space of the parent process (the code is identical). And if it is because of exec, the code snippet for the child process will also be assigned a separate physical space because of the different code executed by the two.

5, the fork () function implementation process

http://blog.csdn.net/shenwansangz/article/details/39184789

Fork () function--parent-child process resource question