Fork() vs Vfork(): Performance & Memory Showdown
Fork() creates a full, independent copy of the parent process’s virtual address space, while Vfork() shares the parent’s memory until exec is called; both are POSIX syscalls but differ drastically in scope and safety.
Engineers reach for Vfork() when spawning short-lived helpers like CGI scripts on memory-tight routers, yet later find mysterious crashes—memory sharing feels faster, but any parent write can corrupt the child, so Fork() often re-enters the codebase disguised as a “fix”.
Key Differences
Fork() duplicates page tables with copy-on-write, letting both parent and child modify memory safely. Vfork() suspends the parent and hands the child the exact same pages, eliminating duplication overhead but forbidding any parent activity until exec/exit; this yields a 5–10× speed boost yet zero safety net.
Which One Should You Choose?
Use Fork() for everyday daemons, multithreaded servers, or anything long-lived. Reserve Vfork() only for micro-utilities where exec arrives within micro-seconds and memory is measured in kilobytes; otherwise the risk of silent corruption outweighs the micro-optimisation.
Examples and Daily Life
Imagine a Raspberry Pi camera script: Fork() lets parent and child both tweak image buffers safely, while Vfork() could crash the parent mid-capture. On an embedded router with 16 MB RAM, Vfork() safely launches a 20 KB udhcpc helper, then execs into /bin/sh without wasting a page.
Can I call printf after Vfork()?
No—any parent stack or heap access is undefined behaviour; stick to exec or _exit immediately.
Does Fork() always duplicate 4 GB instantly?
No; modern kernels use copy-on-write, so pages are duplicated only when either process writes to them.
Is Vfork() obsolete?
Not yet; it still shines in ultra-constrained embedded builds where every kilobyte counts and exec follows within milliseconds.