When running the fork call to create a new process, if it succeed it returns either 0 (the child) or the parent.

I didn't get the idea behind this. Why doesn't fork just always return child or always parent?

  • 6
    It always returns both, unless it fails.
    – zwol
    Commented Apr 27, 2017 at 19:26
  • It may be instructive to read the specification Commented Apr 27, 2017 at 19:41
  • As a programmer convenience to tell whether the code following the fork() should act as the parent or the child without needing to check the process id, etc. Because a parent needs to keep track of the child and handle exits to prevent zombies, and the child needs to do the thing it was invoked for.
    – simpleuser
    Commented Apr 27, 2017 at 20:41
  • Do you actually know what fork does? Commented Apr 27, 2017 at 22:20

2 Answers 2


When you fork(), the code that’s running finds itself running in two processes (assuming the fork is successful): one process is the parent, the other the child. fork() returns 0 in the child process, and the child pid in the parent process: it’s entirely deterministic.

This is how you can determine, after the fork(), whether you’re running in the parent or the child. (And also how the parent knows the child pid — it needs to wait on it at some point.)

In a little more detail:

  • the future parent process calls fork();
  • the kernel creates a new process, which is the child, and sets various things up appropriately — but both processes are running the same code and are “waiting” for a return from the same function;
  • both processes continue running (not necessarily straight away, and not necessarily simultaneously, but that’s besides the point):
    • fork() returns 0 to the child process, which continues and uses that information to determine that it’s the child;
    • fork() returns the child pid to the parent process, which continues and uses that information to determine that it’s the parent.
  • the fork is executed by the parent process. so I thought we still the parent process and we always get pid` of the child. I dont get the idea of how the current process running fork can become the child process (case it returns 0) Commented Apr 27, 2017 at 16:01
  • 2
    @MakhloufGharbi It duplicates the process context. That's what it's for.
    – Kusalananda
    Commented Apr 27, 2017 at 16:03
  • 1
    @Makhlouf fork() starts a new process, but it doesn’t tell the kernel “here, start a new process and run this piece of code in it” — both the current and the new process continue running the same code. Commented Apr 27, 2017 at 16:05
  • 8
    @Makhlouf imagine if you suddenly spawned an identical twin, with all your memories etc., doing exactly the same thing as you are — how would you know which is the original, and which is the newly-spawned twin? Commented Apr 27, 2017 at 16:06
  • 2
    @StephenKitt Well, clearly I am the original (and me too) Commented Apr 27, 2017 at 19:56

The fork() system call "returns twice", always (unless it fails). In the parent, it returns the PID of the child process, and in the child, it returns zero.

The usual flow is

pid_t pid;
int status;

pid = fork();

if (pid == 0) {
} else if (pid > 0) {
  wait(&status); /* wait for child to exit */
} else {
  /* handle failure to fork */

... or similar.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .