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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2761 invoked from network); 28 Sep 2021 17:55:52 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 28 Sep 2021 17:55:52 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0B30F9CAFF; Wed, 29 Sep 2021 03:55:47 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6ECE49CAE4; Wed, 29 Sep 2021 03:55:08 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1C64A9CAE4; Wed, 29 Sep 2021 03:55:06 +1000 (AEST) X-Greylist: delayed 516 seconds by postgrey-1.36 at minnie.tuhs.org; Wed, 29 Sep 2021 03:55:03 AEST Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id D58A89CAE3 for ; Wed, 29 Sep 2021 03:55:03 +1000 (AEST) Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for 'more.local': Unknown host)more.local ((no PTR matching greeting name)d207-6-82-137.bchsia.telus.net[207.6.82.137] port=55055) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (5607 bytes) (sender: ) (ident using UNIX) id for ; Tue, 28 Sep 2021 13:46:26 -0400 (EDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #78 built 2020-Mar-25) Received: from (invalid client hostname: the DNS A record (with the targegt address [10.0.1.129]) for the hostname 'more.local' does not match the expected address [10.0.1.129])more.local ((no PTR matching greeting name)xentastic.local[10.0.1.140] port=60228) by more.local([10.0.1.129] port=25) via TCP with esmtp (5101 bytes) (sender: ) id for ; Tue, 28 Sep 2021 10:46:25 -0700 (PDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2015-Feb-17) Message-Id: Date: Tue, 28 Sep 2021 10:46:25 -0700 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/26.1 (x86_64--netbsd) MULE/6.0 (HANACHIRUSATO) X-Face: ; j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --pgp-sign-Multipart_Tue_Sep_28_10:46:13_2021-1 Content-Type: text/plain; charset=US-ASCII [[ I'm digging through old mail -- my summer has been preoccupied by things that kept me from most everything else, including computing. ]] At Sun, 1 Aug 2021 18:13:18 -0600, Andrew Warkentin wrote: Subject: Re: [TUHS] Systematic approach to command-line interfaces > > 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. That's actually what fork(2) is, effectively -- it sets up a new process that then effectively has control over its own destiny, but only by using code supplied by the parent process, and thus it is also working within the limits of the Unix security model. The fact that fork() happens to also do some of the general setup useful in a unix-like system is really just a merely a convenience -- you almost always want all those things to be done anyway. I agree there is some messiness introduced in more modern environments, especially w.r.t. threads, but there is now general consensus on how to handle such things. I'll also note here instead of in a separate message that Ted's followup questions about the API design and security issues with having the parent process have to do all the setup from its own context are exactly the problems that fork() solves -- the elegance of fork() is incredible! You just have to look at it the right way around, and with the Unix security model firmly in mind. I personally find spawn() to be the spawn of the devil, worse by a million times than any alternative, including the Multics process model (which could have made very good use of threads to increase concurrency in handling data pipelines, for example -- it was even proposed at the time). Spawn() is narrow-minded, inelegant, and an antique by design. I struggled for a very long time as an undergrad to understand the Multics process model, but now that I know more about hypervisors (i.e. the likes of Xen) it makes perfect sense to me. I now struggle with liking the the Unix concept of "everything is a file" -- especially with respect to actual data files. Multics also got it right to use single-level storage -- that's the right abstraction for almost everything, i.e. except some forms of communications (for which Multics I/O was a very clever and elegant design). The "unix" nod to single level storage by way of mmap() suffers from horribly bad design and neglect. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Tue_Sep_28_10:46:13_2021-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCYVNU6gAKCRBie18UwlnH hRoHAJ9QU/y5kEyOEP0hAcxDwOHzlPphbgCdFZDbelj7GltZ5S6bH+oMNNaSzBk= =uu5J -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Sep_28_10:46:13_2021-1--