From: Jim Capp <email@example.com>
To: Richard Salz <firstname.lastname@example.org>
Subject: Re: [TUHS] "Fork considered harmful"
Date: Fri, 12 Apr 2019 11:11:47 -0500 (EST) [thread overview]
Message-ID: <32714704.14145.1555085507471.JavaMail.root@zimbraanteil> (raw)
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
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".
From: "Richard Salz" <email@example.com>
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/
[-- Attachment #2: Type: text/html, Size: 3795 bytes --]
next prev parent reply other threads:[~2019-04-12 16:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 23:06 Richard Salz
2019-04-10 23:24 ` Bakul Shah
2019-04-10 23:37 ` George Michaelson
2019-04-11 11:38 ` Tony Finch
2019-04-11 23:37 ` Chris Hanson
2019-04-12 0:12 ` Derek Fawcus
2019-04-12 16:11 ` Jim Capp [this message]
2019-04-12 14:51 Noel Chiappa
2019-04-12 15:33 ` Warner Losh
2019-04-12 19:55 ` Dan Cross
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).