| Introduction | Memory management (i386/Linux) |
| Processes | File Systems |
| Scheduling (Linux) | Deadlock |
| Synchronisation (Unix) | Devices |
What is scheduled first after a fork?
According to Section 3.2.3 (Process Scheduling) from "Advanced
Linux programming" (Mark Mitchell, Jeffrey Oldham, Alex Samuel,
Sams Publishing, 2001):
Linux schedules the parent and child process independently; there's no guarantee of which one will run first, or how long it will run before Linux interrupts it and lets the other process (or some other process on the system) run.
However, the following passage from Section 3.4.1.1 of "Understanding the Linux Kernel, 3rd Edition" (Daniel P. Bovet, Marco Cesati, O'Reilly, 2005) is more up-to-date and sounds much more convincing:
If the child will run on the same CPU as the parent, and parent and child do not share the same set of page tables (CLONE_VM flag cleared), it then forces the child to run before the parent by inserting it into the parent's runqueue right before the parent. This simple step yields better performance if the child flushes its address space and executes a new program right after the forking. If we let the parent run first, the Copy On Write mechanism would give rise to a series of unnecessary page duplications. Otherwise, if the child will not be run on the same CPU as the parent, or if parent and child share the same set of page tables (CLONE_VM flag set), it inserts the child in the last position of the parent's runqueue.
| Introduction | Intermediate code generation |
| Lexical Analysis | Run-time environments |
| Parsing | Code generation |
| Syntax-directed translation | Code optimisation |
Non-LL(k) grammars (see the example near the end of the page)