User: Password:
Subscribe / Log in / New account

Toward reliable user-space OOM handling

Toward reliable user-space OOM handling

Posted Jun 9, 2013 12:27 UTC (Sun) by mpr22 (subscriber, #60784)
In reply to: Toward reliable user-space OOM handling by cortana
Parent article: Toward reliable user-space OOM handling

Because generally when emacs forks, it's likely to want to capture the output and/or control the input of whatever program the child execs. This is nearly painless with fork(), and a hideous mess with vfork().

(Log in to post comments)

Toward reliable user-space OOM handling

Posted Jun 18, 2013 12:16 UTC (Tue) by nix (subscriber, #2304) [Link]

I suppose it could in theory have used posix_spawn*(), which were added to make no-MMU POSIX implementations happy (which must implement fork() via immediate copying) and are in themselves an indictment of the non-fork()/exec() model, with a huge proliferation of functions for every possible thing that you might want to do between fork() and exec(). Except of course that it's not every possible thing, it's just a few things, and if you want to add a new thing you need to change the libc implementation (at least; quite possibly the kernel implementation on some platforms) and jam it through the Austin Group and wait for years, while in the fork()/exec() model it's just a few lines of code and a few minutes' work.

fork()/exec() is so clearly the Right Thing in this respect that I can't imagine why anyone ever argues against it. But people still do! (Though not here. This has been your out-of-place rant for the day.)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds