Re: Using vfork() in do_system() instead of fork()

[David Wuertele <dave+libc-help at wuertele dot com>]

Mike said:
> i can almost guarantee you that drepper would tell you to go away, especially
> because your "problem" only manifests when you've turned off over commit.

I didn't realize there was a recommended overcommit setting with glibc.
I tried looking for documentation of that, but I can't find it.

> vfork() has ugly semantics whose implications are often not terribly clear
> until it's too late whereas fork() is always straightforward.

I would like to understand more about vfork()'s ugly semantics.  If there is
a ramification that could bite me if I use vfork() instead of fork(), I need to
make sure I understand it before taking the risk.

I have read the source for vfork (at least
sysdeps/unix/sysv/linux/mips/vfork.S),
and it seems to simply be a clone(CLONE_VM | CLONE_VFORK | SIGCHLD).
In fact, I have also implemented my version of do_system() using just
clone() and execl(), and it works the same as vfork().  I am perfectly happy
using clone() and execl() directly if it simplifies the semantics.

The "gotchas" that I am aware of include (and these are true of
clone/execl as well as vfork) that the function that calls vfork()
must never return in the child, otherwise it corrupts the stack frame.  Also,
the function that calls vfork() must not do anything significant
before calling one of the functions of the exec() family, or _exit().

I think that both of these ramifications are non-issues in do_system(),
because the child immediately calls execl().  So what other ramifications
are there?

Thanks,
Dave