From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8704 invoked from network); 2 Aug 2021 00:13:38 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2021 00:13:38 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 707549CA64; Mon, 2 Aug 2021 10:13:35 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6BB339CA63; Mon, 2 Aug 2021 10:13:23 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="L4ofIyYC"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 2C9549CA63; Mon, 2 Aug 2021 10:13:22 +1000 (AEST) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by minnie.tuhs.org (Postfix) with ESMTPS id E06929CA60 for ; Mon, 2 Aug 2021 10:13:20 +1000 (AEST) Received: by mail-lf1-f41.google.com with SMTP id b6so7689101lff.10 for ; Sun, 01 Aug 2021 17:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bupoB4pdgDTAcBfPwcNuD4onzBbfJkskbH/ZAkHv8yI=; b=L4ofIyYCMABjCtTx0tTaypVGI6TVyC52e1t4B5j6qcHey4iElSVdd0+4Q54/phkX0X 7TL48aH/7SGQy/HjHeBJxkMH/mbtGW2AMJAG0zF1jQVNoc0lt0yQygvbxmae+p9GYm2l WCzY781Yj+jS71ykAp7EKNelKdb6yeyQAsjhrJacaAfQDanfjNzZcqI+fmw73ZsmE0NM +FU/cHQS0JmD7c/IWEIroudAHbVECbhlZbUZXOaLkrgM5EGSQfjLtM7IUQzi6VTtyA/Z doMZ83i+HtIVIsoVw3MsGuagA+pSypYevLyhzHX8CE+FtQiYVsMhC1WzgGGvgiz89vM/ GuZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bupoB4pdgDTAcBfPwcNuD4onzBbfJkskbH/ZAkHv8yI=; b=cB5vdJ6oCj7WjnniptPDVh90nJPhTtXLYz1Ewj9C7TwkOP2RNy0C3/FLqG8aDp0u4r bhxMtQaEmfqHUAG8LF8/uPtujQW5EIaw7tP/v8qO4C4AptUSVQDcxXW8UbHxlNvidv9n x0RPy031oOEdsFfiEI0ZiJv3GdKoGQIkirnk4MejnDsA45udFm1ryfeU4n7cFaL5FbWg O554c495520txaMBBrWMYvza/ZHKfSvbId2OuP4dxRofYyd3sXCTSi8GZpmS5EpIn27L kgbqaVOkR52TTr5V+EkL8sNe0VqJjMMYWNfb7lnYA+1RmMeUZ/qJ6W2mcpZ0kESvw3UK yNZg== X-Gm-Message-State: AOAM530rlzlwu8v0B3hYB9uyyMipjh3uSCzh8F6DJIw15wfa7EB0xPL5 0IVNp/17o2M9ghF+49onAUVbXCz53fCJBQq+6Z/gYMRibKY= X-Google-Smtp-Source: ABdhPJw8MVP6qXvgzCwDK1Oo6+3co5JhI7Bf86nSb67QGDar4HF4uLcy27PqilPCOhPOvPDj5Px/HunZxrQiNHyh+5I= X-Received: by 2002:ac2:4e0b:: with SMTP id e11mr2474603lfr.402.1627863198922; Sun, 01 Aug 2021 17:13:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:a288:0:0:0:0:0 with HTTP; Sun, 1 Aug 2021 17:13:18 -0700 (PDT) In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> From: Andrew Warkentin Date: Sun, 1 Aug 2021 18:13:18 -0600 Message-ID: To: TUHS main list Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Systematic approach to command-line interfaces 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" On 8/1/21, John Cowan wrote: > > 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.pdf> > 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. > There's a third kind of primitive that is superior to either spawn() or fork() IMO, specifically one that creates a completely empty child process and returns a context that lets the parent set up the child's state using normal APIs. To start the child the parent would either call exec() to start the child running a different program, or call a new function that starts the child with a parent-provided entry point and whatever memory mappings the parent set up. Both fork() and spawn() could be implemented on top of this easily enough with basically no additional overhead compared to implementing both as primitives. This is what I plan to do on the OS I'm writing (manipulating the child's state won't require any additional primitives beyond regular file I/O since literally all process state will have a file-based interface).