Date: Wed, 27 May 2009 15:10:31 +0200 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: yuri@rawbw.com Cc: Nate Eldredge <neldredge@math.ucsd.edu>, freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? Message-ID: <86ljoig08o.fsf@ds4.des.no> In-Reply-To: <4A1594DA.2010707@rawbw.com> (yuri@rawbw.com's message of "Thu, 21 May 2009 10:52:26 -0700") References: <4A14F58F.8000801@rawbw.com> <Pine.GSO.4.64.0905202344420.1483@zeno.ucsd.edu> <4A1594DA.2010707@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Yuri <yuri@rawbw.com> writes:
> I don't have strong opinion for or against "memory overcommit". But I
> can imagine one could argue that fork with intent of exec is a faulty
> scenario that is a relict from the past. It can be replaced by some
> atomic method that would spawn the child without ovecommitting.
You will very rarely see something like this:
if ((pid =3D fork()) =3D=3D 0) {
execve(path, argv, envp);
_exit(1);
}
Usually, what you see is closer to this:
if ((pid =3D fork()) =3D=3D 0) {
for (int fd =3D 3; fd < getdtablesize(); ++fd)
(void)close(fd);
execve(path, argv, envp);
_exit(1);
}
...with infinite variation depending on whether the parent needs to
communicate with the child, whether the child needs std{in,out,err} at
all, etc.
For the trivial case, there is always vfork(), which does not duplicate
the address space, and blocks the parent until the child has execve()d.
This allows you to pull cute tricks like this:
volatile int error =3D 0;
if ((pid =3D vfork()) =3D=3D 0) {
error =3D execve(path, argv, envp);
_exit(1);
}
if (pid =3D=3D -1 || error !=3D 0)
perror("Failed to start subprocess");
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ljoig08o.fsf>