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.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10366 invoked from network); 2 Aug 2021 00:29:07 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2021 00:29:07 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id CD61B9CA67; Mon, 2 Aug 2021 10:29:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C81999CA64; Mon, 2 Aug 2021 10:28:48 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2D9AF9CA63; Mon, 2 Aug 2021 10:28:46 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id A807D9CA60 for ; Mon, 2 Aug 2021 10:28:45 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 5D41C35E11A; Sun, 1 Aug 2021 17:28:45 -0700 (PDT) Date: Sun, 1 Aug 2021 17:28:45 -0700 From: Larry McVoy To: John Cowan Message-ID: <20210802002845.GC3388@mcvoy.com> References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> <20210801234950.GB3388@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210801234950.GB3388@mcvoy.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Sun, Aug 01, 2021 at 04:49:50PM -0700, Larry McVoy wrote: > On Sun, Aug 01, 2021 at 07:36:53PM -0400, 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. > > When we were working on supporting BitKeeper on Windows, MacOS, all the > various Unix versions, and Linux, we implemented all the needed libc > stuff on Windows (so we could pretend we were not running on Windows). > Everything except fork(), we made a spawnvp() interface. That's the > one thing that made more sense than the Unix way. I have called fork() > directly in decades. s/have/have not/ called fork().... Sigh. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm