Fork rule #3: After a successful fork, both the parent and child process execute code in parallel.

At first glance, this rule looks pretty much the same as the first rule. But no, what's being stressed here is parallelism. The parent's and child's execution paths run in parallel with each other.

You might wonder how on a single (uni) processor system, this can be? Well, that's right: a fundamental attribute of a modern processor is that exactly one machine instruction can run at any given point in time. So, if we're on a uniprocessor box, it just means that the processes will be time-slicing (or timesharing) on the CPU. So, it's pseudo-parallel; however, the speed of a modern CPU being what it is, a human user will perceive the execution as being in parallel. On a multicore (SMP) system, they would, or could, run truly in parallel. So, the detail regarding a uni-processor is just that: a detail. The key point is that we should visualize both the parent and child as executing code in parallel.

So, in the previous code example, this rule tells us that the entire code paths of the parent and child processes will run in parallel; visualizing this parallelism is really the initial difficulty of the fork for folks new to it! To help  with precisely that, see the following figures (though we only show the code of the switch-case for brevity): the parent's code path is highlighted in one color (red), and the child's code path in another color (blue):

This is the key point: the code in blue and the code in red, the child and parent processes, run in parallel!

In the second diagram, the blue and red timeline arrows are used to again depict this parallelism.