Forking

Wednesday, September 25, 2002

Forking

Processes in Unix are created by the fork system call.  The fork call starts the kernel running.  It creates a duplicate of the parent process that caused the fork to be called.  The newly created process (the child process) is created in such a way that it appears that it called fork and is just returning from it when that child process is scheduled to run.

Suppose that the context of a process looks like below.  It has regions in memory for its program, data, and stack.  It also has two files open and has a current directory set.  It is evidently process 25.

Then after the copy part of the fork a new process exists that looks just like the parent, except that it has a new copy of the program, data, and stack somewhere else in memory.  The child was given process number 456. Thus, the child inherits the same data values for program variables as the parent had at the time of the fork.  When the child starts running, however, any variable modifications are made to its data area only.

Notice that the parent and the child to share files that were opened or created by the parent prior to the fork, though.

A final thing to note is that program code can actually be shared, because it is not modifiable anyway.  Most modern Unix variants do share program code.  You might wonder how, if the program has a line like A := 5; the correct A in the correct program data area is modified depending on whether the process executing is the parent or the child.  That is the magic of virtual memory.  When a process is loaded, the page table registers for virtual memory are set to point to the correct places in memory (e.g., the data area) for that process.  So, even though A has the same virtual address regardless of which process is running, when that address is translated by the virtual memory management unit of the processor via the page tables, the correct location for A is found depending on whether the parent or child is running.

One last thing not shown in the above illustrations is the kernel stack.  When the child process gets to start running for the first time, it starts in kernel mode at the end of the fork call, as if returning from the fork call.  Somehow the OS must ensure that the value returned from fork in that case is 0 (perhaps is forces the program stack to have a 0 on top when it does the copying).  That way, the code can be included in the program (which is the same for both processes) that checks this return value.  If the return from fork is a zero, code can be executed that is meant for the child process.  The value returned to the parent is the PID of the child.