2 Aug
2021
2 Aug
'21
2:28 a.m.
On Sun, Aug 01, 2021 at 04:49:50PM -0700, Larry McVoy wrote:
On Sun, Aug 01, 2021 at 07:36:53PM -0400, John Cowan
wrote:
s/have/have not/ called fork()....
Sigh.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
Nowadays it's a question whether fork()
makes sense any more. "A fork()
in the road" [Baumann et al. 2019] <
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.…
is an interesting argument against fork():
* It doesn't compose.
* It is insecure by default.
* It is slow (there are about 25 properties a process has in addition to
its memory and hardware state, and each of these needs to be copied or not)
even using COW (which is itself a Good Thing and can and should be provided
separately)
* It is incompatible with a single-address-space design.
In short, spawn() beats fork() like a drum, and fork() should be
deprecated. To be sure, the paper comes out of Microsoft Research, but I
find it pretty compelling anyway.
When we were working on supporting BitKeeper on Windows, MacOS, all the
various Unix versions, and Linux, we implemented all the needed libc
stuff on Windows (so we could pretend we were not running on Windows).
Everything except fork(), we made a spawnvp() interface. That's the
one thing that made more sense than the Unix way. I have called fork()
directly in decades.