System calls: fork, exec and wait
Goals and model
Distinguish a request to the kernel from an ordinary function call, trace process creation, and separate creation, replacement and waiting. Prerequisite: the published processes/threads lesson. UNIX-like APIs are a concrete teaching model; their names are not universal OS requirements. Unless stated otherwise, all operations succeed, programs are single-threaded, no signals interrupt waits, and output buffering is excluded by counting explicit abstract emit operations rather than printf output.
1. A protected service counter
Imagine a library where visitors cannot enter the locked records room. They submit a request at a service counter; authorized staff check it and act. User mode resembles the visitor area and kernel mode the protected room. A system call is a controlled request for an OS service, such as reading a file or creating a process. Hardware-supported entry transfers control to a kernel handler, which checks arguments and permissions and eventually returns a result or error.
The analogy does not mean each request creates a new employee: entering the kernel is not automatically switching to another process. A mode transition changes privilege; a process context switch changes the execution context being scheduled. A read that can complete immediately may return to the same process. A read that must await input may block it and allow another process to run. Neither every function call nor every library call is a system call. A library can compute entirely in user space, buffer requests, or wrap one or several kernel operations.
2. fork: one execution becomes two
A successful fork creates one child. Both parent and child continue just after that fork. The child receives return value 0; the parent receives the child's positive process identifier. Failure returns −1 to the caller and creates no child. Do not infer scheduling order from these return values.
The child has a separate virtual address space. Ordinary private variables initially have the same values, but later writes in one process do not change the other's private variables. Copy-on-write can avoid immediate physical copying; it preserves the logical isolation, so physical implementation is not a reason to treat private variables as shared.
Worked trace: start with private x=6. After one successful fork, the child executes x=x+4 and the parent executes x=x−1. The child's x is 10 and the parent's x is 5. There is no single final shared x. In contrast, explicitly shared memory has a different contract.
3. Counting executions, not lines of source
Suppose each process executes three consecutive unconditional successful fork calls and then emits one token. Process counts after each call stage are 1→2→4→8, so eight tokens are emitted and seven new children have been created. The original process is included in the total eight. This doubling rule needs every extant process to reach every remaining fork.
Conditional example: execute p=fork(); if p==0 then fork(); then emit one token. The first fork gives parent P and child C. Only C performs the second fork, producing D. P, C and D each emit, so there are three tokens. Draw the branching tree before applying powers of two. A successful exec or an early exit can remove later code paths from the count.
4. exec: same process, new program
A successful exec-family operation replaces the caller's program image and begins the new program. It does not create an extra process; the process identifier is retained. The old program's statement immediately after exec is not executed on success. If exec fails, it returns an error and the old program continues, so failure handling matters.
Worked trace: a parent forks one child. The child successfully execs program B, which emits B and terminates. The parent waits successfully for that child's termination, then emits P. There are two processes, and the emit order is B then P. The parent's wait creates the order; fork alone would not. The new program's behavior, not the discarded old code, determines the child's later actions.
5. wait: collect termination information
A successful wait for a specified child's termination allows the parent to collect termination status and reap the child. If the child has already terminated, the wait need not block. If it is still running, an ordinary blocking wait can suspend the parent. A terminated but unreaped child is a zombie: it is not still executing instructions. An orphan is a process whose parent terminated; orphan and zombie describe different conditions.
In problems with several children, distinguish waiting for any child from waiting for a specified child. A successful wait for child C does not by itself order unrelated child D. Assumptions about errors, signals and nonblocking flags must be stated rather than hidden.
Exam method and misconceptions
Mark each process's path, count successful creations, and cross out code replaced by a successful exec. Track private values per process. Add ordering edges only for stated synchronization. Then distinguish total processes, new children and number of output operations. Do not equate a system call with a context switch, exec with fork, or a zombie with a blocked running program.
Original practice: six single-correct MCQs
Choose exactly one option. Each question states its own required assumptions.
SC01. A process makes three consecutive unconditional fork calls. All succeed and every descendant reaches all remaining calls. How many processes exist afterward, including the original?
A. 3 B. 4 C. 7 D. 8
Answer: D
A: Three counts source calls, not executions.
B: Four is the count after two stages.
C: Seven is the number of newly created children.
D: The counts double: 1→2→4→8.
SC02. Starting from one process, execute p=fork(); only if p==0 execute one further fork(); then every process emits once. Both calls succeed where executed. How many emissions occur?
A. 2 B. 3 C. 4 D. 1
Answer: B
A: This omits the child of the conditional fork.
B: The original parent, first child and second child each emit once.
C: The parent does not execute the conditional fork.
D: Successful creation produces additional emitting processes.
SC03. A process successfully execs another program. Which statement is correct?
A. A new child is necessarily created B. Its PID necessarily changes C. Its program image is replaced while its PID is retained D. The next statement in the old program executes
Answer: C
A: Creation is the role of fork in this model.
B: Successful exec retains process identity.
C: Replacement is not process creation.
D: Only a failed exec returns to the old continuation.
SC04. Private x=9 is copied logically by a successful fork. The child subtracts 2; the parent adds 3. Neither uses shared memory. What are parent and child values?
A. 10,10 B. 12,7 C. 7,12 D. 12,12
Answer: B
A: Combining both updates incorrectly assumes shared x.
B: Parent computes 9+3=12; child computes 9−2=7 independently.
C: The roles have been reversed.
D: The parent update does not modify the child copy.
SC05. Child C emits C and terminates. Parent successfully waits for C to terminate, then emits P. Output buffering and errors are excluded. What emission order is guaranteed?
A. P before C B. C before P C. Either order D. P is never emitted
Answer: B
A: P is after the successful termination wait.
B: C is emitted before termination, which precedes completion of the parent wait.
C: The stated wait supplies an ordering constraint.
D: Successful wait allows the parent to continue.
SC06. Which implication is valid in a conventional protected OS?
A. Every system call switches to a different process B. Every library function enters the kernel C. A system call requests a kernel service through a controlled entry D. A zombie is a child still executing user instructions
Answer: C
A: A privilege transition need not schedule another process.
B: Pure user-space computation need not enter the kernel.
C: Controlled entry is the service boundary.
D: A zombie has terminated but has not yet been reaped.
Sources and scope
This original lesson extends the existing OS foundations in the GATE 2026 course. It maps to Section 8 of the official 2026 syllabus; it is not a claim of complete OS coverage or GATE 2027 completeness. Practice questions are original, not past-exam questions.
Sources checked 2026-10-14.
Sign in to keep your progress. Sign in