From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 3ef09fc2 for ; Wed, 10 Apr 2019 23:38:29 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 42BA294985; Thu, 11 Apr 2019 09:38:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id DFDC694926; Thu, 11 Apr 2019 09:38:02 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=algebras-org.20150623.gappssmtp.com header.i=@algebras-org.20150623.gappssmtp.com header.b="etNSTH7v"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B818D94926; Thu, 11 Apr 2019 09:37:58 +1000 (AEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by minnie.tuhs.org (Postfix) with ESMTPS id 52A1194925 for ; Thu, 11 Apr 2019 09:37:56 +1000 (AEST) Received: by mail-io1-f65.google.com with SMTP id e13so3756323ioq.6 for ; Wed, 10 Apr 2019 16:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qViaLFwVLkfV1qFsQf4aZjjBMT6CnGmDm87704E7llg=; b=etNSTH7vUaOhDlJq00PJHySAdoEIDNANvrLCtGn9JRc9Cm4XKMTxamK1MROMlmBv/B 5glS9Nxy768Kk41r/t6LOtRHAo/dzAebjWSWnYTRoGuX7WA+mVvx27tDNyhzYJzWrqgu aWW2tkT6b2ZiMC00ekhEhA2HVL1dYLM66w+yP73E+z0z4Sqaydli1wlWasQeObtWrTBS +fq8SD6ukX9MgpUKIOgeB8RlYE5WuwYuxa/UILTnxFn6bGhvNJXkOMJBiuvtvlrWfvmZ 9HarBeqYmXS1AVqqxicklzsPzudLe7WPRks6xwr6+kXQUf8Yaui2DtK3nnlaN0JcNR49 giUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qViaLFwVLkfV1qFsQf4aZjjBMT6CnGmDm87704E7llg=; b=f0j76XQQS2IwGzXoSTMIT3yqFvsC3uN25UkkcuOvRjzUM+nTVMG4UUR67KjWN9Jyav 38U4n0Ocwv8C/aSbNvC0bIjCtwoqXp8pUuMU9ro1DoHwg9+Fg9RUSJbzELxS6Ntx9nmk CbGbwCbSZ5Dr9y5wuDY1QQ8fb41KsXKJypSKGAfbIU4dgvLWeX7BKREqxn4J/N6+I+E6 6GNQTgflF3Fa7JjIaLCPlMptb+kMA2jjJSnTWH5/B/2pdEwkSIMjV6OAQ6lOACKYdkQ5 7TiAvpaPaI+4Sa3kf7ZR1RH66kEZbitNW7jnXBe32YTpt2wEvZOp+1yMX/AFaidNErH5 HQPA== X-Gm-Message-State: APjAAAXsvzoFDAJXSKqE0twk3MRyLWBFbWlFoFEIvx7yifBFV/E2mM7U i7ByUmYURkE8lCSmrdGpC43b9kqTynM5TLDc9KBbAxg32Fo= X-Google-Smtp-Source: APXvYqw2CcRkaPlYdj/4JDzrQxXAB8ajky4fUjJEHHmsrb1NtQzwyZ/3y9yBpIzBvaiGDNftldwnNxO3uGz7aLW4p+8= X-Received: by 2002:a6b:680f:: with SMTP id d15mr12065217ioc.116.1554939475438; Wed, 10 Apr 2019 16:37:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Thu, 11 Apr 2019 09:37:44 +1000 Message-ID: To: The Eunuchs Hysterical Society Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] "Fork considered harmful" X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" 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 wrote: > > On Apr 10, 2019, at 4:06 PM, Richard Salz 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. > >