== _fork()_ versus strict virtual memory overcommit handling

Unix's _fork()_ is in many ways a wonderful API, but people who want
[[strict virtual memory overcommit handling MemoryOvercommit]] find
it deeply problematic.  This is because, [[as I've written before
WhyVforkI]], _fork()_ is probably the leading way on Unix systems to
(theoretically) allocate a lot of memory that you will never use.
The more allocated but unused memory you have, the stupider strict
overcommit gets ([[cf ../linux/NonStrictOvercommitDefault]]); it
increasingly denies allocations purely for accounting reasons, instead
of from any danger that the system will actually run out of RAM. The
corollary is that it's hard to argue that strict overcommit should be
the default if systems routinely have significant amounts of allocated
but unused memory.

(Why _fork()_ is a good API is another entry. The short version is
that _fork()_ is a *kernel* API, not necessarily a user one.)

It's possible to argue that many instances of unused memory are bad
programming practices (or mistakes), and so can at least in theory
be discounted when advocating for strict overcommit. This argument
is much harder to make with _fork()_. Straightforward use of _fork()_
followed by _exec()_ can be replaced by APIs like the much more
complicated [[_``posix_spawn()''_
http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html]]
but there are plenty of other uses of _fork()_ that cannot be
(even some uses of fork-then-exec, since _``posix_spawn()''_ can't do
things like change process permissions).

(In the extreme, the arguments of the strict overcommit crowd then boil
down to 'well, _fork()_ complicates our life too much so you shouldn't
be allowed to use it'. This may sound harsh but it's really what it
means to say that historic and natural uses of _fork()_ are now bad
practice, at least without a really good reason why.)

PS: [[_vfork()_ is a hack WhyVforkI]]. [[Really WhyVforkII]].