The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: George Michaelson <ggm@algebras.org>
To: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] "Fork considered harmful"
Date: Thu, 11 Apr 2019 09:37:44 +1000	[thread overview]
Message-ID: <CAKr6gn3-qgbsDaqvr5n-Ojaa9CS2Y+PnSD2AjNbu+9-bCX1TMA@mail.gmail.com> (raw)
In-Reply-To: <A9713625-715B-42B1-8FFA-E6A481A69E11@bitblocks.com>

I don't pay much attention to this stuff any more but I do recall
being absolutely *astonished* how complex the re-binding of process to
inherited I/O was in a lot of systems in the 1980s

fork() and the various exec() flavours had this single compelling
story for me: the stdin/stdout/stderr *and all other open I/O* was
inherited across the process boundary. This alone made writing code
significantly easier.

I did briefly find myself in a world where it wasn't clear where an
X.25 binding was (this was Yorkbox, and then the UCL-CS version of the
same idea, and the per-ISODE OSI stack work) on an FD, but it wasn't
immediately clear which.

We wound up passing a binary-encoded text blob in the execve() info to
"inform" the child what it was meant to look for in file descriptors,
to (re)bind as the X.25 FD to work with. It felt really creepy to do
this, but we simply couldn't find a way round it.

Other systems "for your convenience" felt it was far, far kinder to
either completely obscure the binding of I/O or even terminate it.
Truly bizarre.

Actual runtime cost to mechanise the COW state. and the other bits of
kernel state, and instantiate the process, and fiddly bits were stuff
I simply didn't think about much. it felt like some giant bcopy() call
in the kernel did something in VM aware memory addressing to make a
"copy" of something, which then ran, because it existed. As if you
could clone a vertial slice of the layers of the onion and simply
carry on, irrespective.

But if somebody said VMS or the nascent Microsoft kernel was "better"
I would (and probably still would) be skeptical.

Hard to beat simple.

On Thu, Apr 11, 2019 at 9:25 AM Bakul Shah <bakul@bitblocks.com> wrote:
>
> On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz@gmail.com> wrote:
> >
> > Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
> >
>
> FWIW, my view is that any unix evolution that complicates
> fork() is/has probably going/gone in the wrong direction.
>
>

  reply	other threads:[~2019-04-10 23:38 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 [this message]
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
2019-04-12 14:51 Noel Chiappa
2019-04-12 15:33 ` Warner Losh
2019-04-12 19:55 ` Dan Cross

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKr6gn3-qgbsDaqvr5n-Ojaa9CS2Y+PnSD2AjNbu+9-bCX1TMA@mail.gmail.com \
    --to=ggm@algebras.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).