Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?

Alfred Perlstein alfred at freebsd.org
Thu May 28 21:30:18 UTC 2009


* Dag-Erling Sm??rgrav <des at des.no> [090527 06:10] wrote:
> Yuri <yuri at 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 = fork()) == 0) {
>         execve(path, argv, envp);
>         _exit(1);
> }
> 
> Usually, what you see is closer to this:
> 
> if ((pid = fork()) == 0) {
>         for (int fd = 3; fd < getdtablesize(); ++fd)
>                 (void)close(fd);
>         execve(path, argv, envp);
>         _exit(1);
> }

I'm probably missing something, but couldn't you iterate 
in the parent setting the close-on-exec flag then vfork?

I guess that wouldn't work for threads AND you'd have to
undo it after the fork if you didn't want to retain that
behavior?

thanks,
-Alfred


More information about the freebsd-hackers mailing list