Taming the OOM killer [LWN.net]

Taming the OOM killer

Posted Feb 5, 2009 11:49 UTC (Thu) by alonz (subscriber, #815)
In reply to: Taming the OOM killer by epa
Parent article: Taming the OOM killer

<sarcasm>
So you would prefer the VMS/Win32 style “CreateProcess” system call, with its 30+ arguments—just in order to accommodate all possible behaviors expected from the parent process?
</sarcasm>

This isn't really simpler (except on block diagrams…)

(Log in to post comments)

Taming the OOM killer

Posted Feb 5, 2009 12:52 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

Are you saying that nothing is possible in-between (v)fork plus exec and CreateProcess?

Taming the OOM killer

Posted Feb 5, 2009 20:00 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

(From SUSv2 / POSIX draft.)

The vfork() function has the same effect as fork(2), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit(2) or one of the exec(3) family of functions.

On the other hand, pid_t child = clone(run_child_func, run_child_stack, CLONE_VM, run_child_data) would do the trick. The child would share memory with the parent, making overcommit unnecessary, but would have a different file descriptor table, allowing pipelines to be set up easily.