In my case, I am using
ptrace on the child process. This requires the child process to stop itself before calling
execve, which doesn’t work so well with
vfork. I suppose I could create a new thread first prior to calling
vfork, but that sounds like it could actually slow things down in the case where the memory use is small, since it is creating both a temporary thread and a process.
vfork just scares me. Currently, one version of my code allocates memory after forking, which would of course cause bad things to happen. I have now switched that to an array on stack, since even fork doesn’t make
malloc always safe in the forked process. There is an
fprintf that probably wouldn’t be
vfork-safe, which reports an error that can show up when
seccomp is used. I am currently switching that to a call to
write, because why not make it more efficient anyhow? But knowing just a little of what can go wrong on a
vfork makes me frightened to make use of it.
I agree that in the simple case,
vfork could be a reasonable optimization, although it would seem tempting to use a
posix_spawn variant instead, which pushes the
vfork-correctness obligation onto someone else…
In my example, reducing the memory use made things much faster, and that is certainly a good outcome overall!