How does fork() know when to return 0?

How it works is largely irrelevant - as a developer working at a certain level (ie, coding to the UNIX APIs), you really only need to know that it works.

Having said that however, and recognising that curiosity or a need to understand at some depth is generally a good trait to have, there are any number of ways that this could be done.

First off, your contention that a function can only return one value is correct as far as it goes but you need to remember that, after the process split, there are actually two instances of the function running, one in each process. They're mostly independent of each other and can follow different code paths. The following diagram may help in understanding this:

Process 314159 | Process 271828-------------- | --------------runs for a bit |calls fork     |               | comes into existencereturns 271828 | returns 0

You can hopefully see there that a single instance of fork can only return one value (as per any other C function) but there are actually multiple instances running, which is why it's said to return multiple values in the documentation.

Here's one possibility on how it could work.

When the fork() function starts running, it stores the current process ID (PID).

Then, when it comes time to return, if the PID is the same as that stored, it's the parent. Otherwise it's the child. Pseudo-code follows:

def fork():    saved_pid = getpid()    # Magic here, returns PID of other process or -1 on failure.    other_pid = split_proc_into_two();    if other_pid == -1:        # fork failed -> return -1        return -1    if saved_pid == getpid():  # pid same, parent -> return child PID        return other_pid    return 0                   # pid changed, child, return zero

Note that there's a lot of magic in the split_proc_into_two() call and it almost certainly won't work that way at all under the covers^(a). It's just to illustrate the concepts around it, which is basically:

• get the original PID before the split, which will remain identical for both processes after they split.
• do the split.
• get the current PID after the split, which will be different in the two processes.

You may also want to take a look at this answer, it explains the fork/exec philosophy.

^(a) It's almost certainly more complex than I've explained. For example, in MINIX, the call to fork ends up running in the kernel, which has access to the entire process tree.

It simply copies the parent process structure into a free slot for the child, along the lines of:

sptr = (char *) proc_addr (k1); // parent pointerchld = (char *) proc_addr (k2); // child pointerdptr = chld;bytes = sizeof (struct proc);   // bytes to copywhile (bytes--)                 // copy the structure    *dptr++ = *sptr++;

Then it makes slight modifications to the child structure to ensure it will be suitable, including the line:

chld->p_reg[RET_REG] = 0;       // make sure child receives zero

So, basically identical to the scheme I posited, but using data modifications rather than code path selection to decide what to return to the caller - in other words, you'd see something like:

return rpc->p_reg[RET_REG];

at the end of fork() so that the correct value gets returned depending on whether it's the parent or child process.

In Linux fork() happens in kernel; the actual place is the _do_fork here. Simplified, the fork() system call could be something like

pid_t sys_fork() {    pid_t child = create_child_copy();    wait_for_child_to_start();    return child;}

So in the kernel, fork() really returns once, into the parent process. However the kernel also creates the child process as a copy of the parent process; but instead of returning from an ordinary function, it would synthetically create a new kernel stack for the newly created thread of the child process; and then context-switch to that thread (and process); as the newly created process returns from the context switching function, it would make the child process' thread end up returning to user mode with 0 as the return value from fork().

Basically fork() in userland is just a thin wrapper returns the value that the kernel put onto its stack/into return register. The kernel sets up the new child process so that it returns 0 via this mechanism from its only thread; and the child pid is returned in the parent system call as any other return value from any system call such as read(2) would be.

You first need to know how multitasking works. It is not useful to understand all the details, but every process runs in some kind of a virtual machine controlled by the kernel: a process has its own memory, processor and registers, etc. There is mapping of these virtual objects onto the real ones (the magic is in the kernel), and there is some machinery that swap virtual contexts (processes) to physical machine as time pass.

Then, when the kernel forks a process (fork() is an entry to the kernel), and creates a copy of almost everything in the parent process to the child process, it is able to modify everything needed. One of these is the modification of the corresponding structures to return 0 for the child and the pid of the child in the parent from current call to fork.

Note: nether say "fork returns twice", a function call returns only once.

Just think about a cloning machine: you enter alone, but two persons exit, one is you and the other is your clone (very slightly different); while cloning the machine is able to set a name different than yours to the clone.