Review request for 5049299

Martin Buchholz martinrb at
Sat Jun 27 17:21:58 UTC 2009

Although clone(CLONE_VFORK...) didn't work out,
using glibc's vfork instead did.  The glibc code to handle vfork
is quite different from the code for clone(CLONE_VM | CLONE_VFORK),
especially for saving/restoring pids.

This time, I tested on 32-bit and 64-bit Linux.

Michael, please review.

As always, we'll need a bug filed.
Synopsis: (process) Use vfork, not fork, on Linux to avoid swap exhaustion

And again, my changes are conflicting with Michael's changes for Solaris.
I will negotiate with Michael for who gets to commit first.
We will likely end up with 4 different strategies for "forking":
fork, clone, vfork, and helper process.

Note to integrators: the process changes continue to be high-risk.
Extra JPRT runs might be a good idea.


On Tue, Jun 23, 2009 at 07:51, Christos Zoulas <christos at> wrote:

> On Jun 23,  3:33pm, aph at (Andrew Haley) wrote:
> -- Subject: Re: Review request for 5049299
> | I can debug this.
> |
> | Please try first syscall(SYS_clone ...) to bypass the libc gubbins.
> | That might be all you need.  If that doesn't help I'll have a look.
> |
> | Isn't there some point at which you have to say to a Linux user "Your
> | system is simply misconfigured.  Fix the overcommit parameter and this
> | problem will go away"  ?
> Another thing to try is to add CLONE_VFORK to suspend the parent.
> christos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the core-libs-dev mailing list