I think the problem with fork() is that it's elegance invites people to use it
outside its sweet spot.
I always thought (perhaps wrongly) that fork() didn't have to copy all the memory,
just the stack and user areas, and that VM page table entries were cloned to share the
code segment.
fork() is beautiful for what it is and what it does. Being able to create a mirror image
of the current process, and to be able to share all the I/O and signal states is cool, if
that's what you want. I think the author of the micro$oft article is complaining that
fork() shares too much, and therefore to use it is a security risk.
If you don't want to share all that stuff, maybe you shouldn't be using fork(),
or, you should fork() early, sharing EXACTLY what you want to share and nothing more, and
then differentiate with exec().
C is elegant. C can also be dangerous if you don't use it wisely.
I think the author should take a lesson from "The Kings Toaster".
http://www.ee.ryerson.ca:8080/~elf/hack/ktoast.html
Cheers,
Jim
From: "Richard Salz" <rich.salz(a)gmail.com>
To: tuhs(a)tuhs.org
Sent: Wednesday, April 10, 2019 7:06:23 PM
Subject: [TUHS] "Fork considered harmful"
Any view on this?
https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/