vfork is perfectly predictable as long as you follow the basic rule: only invoke async-signal-safe functions until you call exec. they're explicitly listed but basically boil down to: any functions that more-or-less map directly to a system call, and nothing that could possibly modify process memory or attempt to take a lock (including memory allocation)

it's meant for cases where you want to avoid a bit of the fork overhead or if you need to spawn a subprocess from an existing memory-heavy process without getting a KILL from the kernel if overcommit is disabled (as the fork COW doubles your claim on memory even if you don't actually trigger a copy)