Where fork--child processes start running in Linux

Transfer from http://blog.csdn.net/koches/article/details/7787468The background color of the yellow is I added ... If I can't understand it, I'm bacchanalian .a wonderful thing about a fork call is that it is called only once, but it can return two times, and it may have three different return values:

1) In the parent process, fork returns the process ID of the newly created child process;
2) in the sub-process, fork returns 0;
3) If an error occurs, fork returns a negative value;

After a successful creation of a new process, there are two fundamentally identical processes in the system, which do not have a fixed sequencing and which process first executes the process scheduling policy to look at the system. At this point, two processes are executed from the fork, but the PID is different.
Some people may wonder why they didn't start copying code from # include?

See:

Represents a program that contains a fork, and the fork statement can be seen as cutting the program to A, B, two parts. Then the entire program will run as follows:

Step1, set up by the shell to execute the program directly, generated the process p. P finishes executing part. All the code for a.

Step2, when executing to PID = fork (), p starts a process q,q is a child of P, and P is the process of the same program. Q inherits the current values of all variables, environment variables, and program counters for p.

Step3, in the P process, the fork () returns the PID of Q to the variable PID and proceeds to the part. B's Code.

STEP4, in Process Q, assigns 0 to the PID, and continues to execute part. B's Code .

Here are three points that are critical:

1, p executes all programs, and Q only executes part. B, which is the program behind the fork (). (This is because Q inherits the P's pc-program counter)

2.Q inherits the current environment when the fork () statement executes, not the initial environment of the program.

3. The fork () in P starts the sub-process Q and returns the PID of Q, while the fork () statement in Q does not start a new process and returns only 0.

#include <unistd.h>
#include <sys/types.h>

Main ()
{
pid_t pid;
printf ("hello!\n");
Pid=fork ();

if (PID < 0)
printf ("Error in fork!");
else if (PID = = 0)
printf ("I am the child process, my process ID is%d\n", getpid ());
Else
printf ("I am the parent process, my process ID is%d\n", getpid ());

printf ("bye!\n");
}

Here you can see that the parent process executes printf ("hello!\n"); And the child process did not execute printf ("hello!\n");

There is a very confusing example:

#include <unistd.h>
#include <sys/types.h>

Main ()
{
pid_t pid;
printf ("fork!"); printf ("fork!\n")

Pid=fork ();

if (PID < 0)
printf ("Error in fork!\n");
else if (PID = = 0)
printf ("I am the child process, my process ID is%d\n", getpid ());
Else
printf ("I am the parent process, my process ID is%d\n", getpid ());
}

The print output is now two fork! This makes people think that the child process starts from # include, so it also executes printf ("fork!"); Statement.

In fact, this problem occurs because:

This is related to the buffer mechanism of printf, when some content of printf, the operating system just put the content in the stdout buffer queue, and did not actually write to the screen. However, as soon as you see a \ n, the stdout is refreshed immediately, so you can print it right away.

After the Mian function (parent process) runs printf ("fork!"), "fork!" Just put in the buffer, and then run to fork, the buffer inside the AAAAAA quilt process (child process) inherited, so in the sub-level stdout buffer inside there is also a "fork!". So, what you end up seeing is that "fork!" has been printf 2 times!!!!
When the Mian function (parent process) runs printf ("fork!\n"), "fork!" is immediately printed onto the screen, and then there is no "fork!" in the stdout buffer in the child process to fork to Content so you see the result will be "fork!" was printf 1 times!!!!

Finally this print two times fork problem, in Apue above has talked about, on Apue 8.3 (third edition Chinese edition is 184 page). When I saw it, I forgot that the other day just came across a problem, I had to wonder where the fork began to execute, fortunately this post saved me ... But it also proves that apue is really thick and much content.

Where fork--child processes start running in Linux