3

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 Apr 27 '17 at 19:26
  • It may be instructive to read the specification – Digital Trauma Apr 27 '17 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 Apr 27 '17 at 20:41
  • Do you actually know what fork does? – immibis Apr 27 '17 at 22:20
11

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) – Makhlouf GHARBI Apr 27 '17 at 16:01
  • 2
    @MakhloufGharbi It duplicates the process context. That's what it's for. – Kusalananda Apr 27 '17 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. – Stephen Kitt Apr 27 '17 at 16:05
  • 6
    @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? – Stephen Kitt Apr 27 '17 at 16:06
  • 1
    @StephenKitt Well, clearly I am the original (and me too) – Hagen von Eitzen Apr 27 '17 at 19:56
2

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) {
  run_child_stuff();
  exit(0);
} else if (pid > 0) {
  run_parent_stuff();
  wait(&status); /* wait for child to exit */
} else {
  /* handle failure to fork */
}

... or similar.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.