4 ms·
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
by unilynx 7y ago
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)
- matheusmoreira 7y agoIn general signal safety is lost because the C standard library maintains global and thread-local data. For example, the various I/O functions make use of global buffers. Using the read and write system calls directly is safe: when interrupted, they either report their progress or return EINTR.
- gpderetta 7y ago> vfork is perfectly predictable as long as you follow the basic rule: only invoke async-signal-safe functions until you call exec. Unsurprisingly, that's also true for plain fork in a multithreaded program.
- dooglius 7y agoI disagree, anything not written in inline assembly can potentially lead to the compiler modifying the stack which violates the assumption.