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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24227 invoked from network); 3 Aug 2021 17:14:18 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2021 17:14:18 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 1F8629CA67; Wed, 4 Aug 2021 03:14:17 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3015C9CA63; Wed, 4 Aug 2021 03:13:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ieee.org header.i=@ieee.org header.b="bgXjGXrV"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 5CEC09CA63; Wed, 4 Aug 2021 03:13:47 +1000 (AEST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by minnie.tuhs.org (Postfix) with ESMTPS id 4015C9CA60 for ; Wed, 4 Aug 2021 03:13:44 +1000 (AEST) Received: by mail-lj1-f175.google.com with SMTP id l17so29050262ljn.2 for ; Tue, 03 Aug 2021 10:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=InQmi7oNJNnlGu1UdRmVqGxUAz+YJvdi+DJoEVip5QM=; b=bgXjGXrVHECTOLiSX2dik9jVy3F8zTk8nqn5051Ydaz42i8Pfe1NAaOShc4q/bT+RE OPN1SC62Eym4uZMzHVt/VxE33FRl4+VKFKhDmSJVl/yMZ8uRvquh6swmRaWsVA6kNL6o eC1zROZCszKKPQ0NYE3vSBvfIfvOeIjoGLF0A= 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:cc; bh=InQmi7oNJNnlGu1UdRmVqGxUAz+YJvdi+DJoEVip5QM=; b=VA6ZKn/CDeKXmLIsuURObKotjQQWXkDdmmDObJuDJuyZEWkVRkQXS4JaGVF8gmb8zx Cfmf62jt8SiLBfYlMDMiMxBWgfg95uked+14AKnCaKFjSo3SExZRdqG6iN0PPQ+K8kv8 rBo44dHqlk7U5FEtTfk47qEgOUWNNTmW1SDHOaPb0XE9XFpmJoI43Pr255m1Y+T5rvD4 cmE5fE+6x0kODU9xCkqrG2vvNgCLQVmly2VdzoWm1pa1CUPjpVjo/f2F8348qg+oCVbm 1qxnQSBGaA1y9UCYv+CxmhMpAv/5n9SEbHFB+VOiqyAEczHBP1+g6RWIHGnsFEN+L7Me fqow== X-Gm-Message-State: AOAM533fOvCK2pkm7ArN1Eh5QRJfpAeu+cfp+RpMKnAYu8SsYFtKVzaI a2YqtPDQrftlPxViivCt1a3pUqFTA3mWP4KM+mKmDA== X-Google-Smtp-Source: ABdhPJyjMBI4xX5zsEXZINeiEz2MD1FR5tt4ugibk+xpjp9OsMEvzRrQtA64JsVll433OKmzt3esfnPYrpDxwJ89ipI= X-Received: by 2002:a2e:a44f:: with SMTP id v15mr14970742ljn.301.1628010822134; Tue, 03 Aug 2021 10:13:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 3 Aug 2021 10:13:31 -0700 Message-ID: To: Douglas McIlroy Content-Type: multipart/alternative; boundary="000000000000bece3f05c8aace67" 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: , From: Tom Lyon via TUHS Reply-To: Tom Lyon Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000bece3f05c8aace67 Content-Type: text/plain; charset="UTF-8" I always believed that fork() was the very essence of the beauty of UNIX. So simple, yet so powerful. And it is far simpler than its predecessor on Genie, which looked a lot more like spawn(). With fork, the child inherits properties which may not have existed when the code was written, so it's much easier to reason about the behavior of sub-processes. Fork made writing the shell and pipelines much more obvious. Today we know that threads and shared mutable memory are a really bad idea, it's just that the hardware gave us no alternatives. I claim UNIX is directly responsible for the existence of MMUs in microprocessors. What if CPU designers would add facilities to directly implement inter-process or inter-processor messaging? Sadly, there has to be a dominant software paradigm for the hardware guys to target, so there's a nasty chicken and egg problem. Imagine if the Erlang model of distributed systems had taken off. Go gets us part of the way there, but cross-machine messaging is still a mess. On Tue, Aug 3, 2021 at 8:02 AM Douglas McIlroy < douglas.mcilroy@dartmouth.edu> wrote: > > fork() is a great model for a single-threaded text processing pipeline > to do > > automated typesetting. (More generally, anything that is a > straightforward > > composition of filter/transform stages.) Which is, y'know, what Unix > is *for*. > > > It's not so great for a responsive GUI in front of a multi-function > interactive program. > > "Single-threaded" is not a term I would apply to multiple processes in > a pipeline. If you mean a single track of data flow, fine, but the > fact that that's a prevalent configuration of cooperating processes in > Unix is an artifact of shell syntax, not an inherent property of > pipe-style IPC. The cooperating processes in Rob Pike's 20th century > window systems and screen editors, for example, worked smoothly > without interrupts or events - only stream connections. I see no > abstract distinction between these programs and "stuff people play > with on their phones." > > It bears repeating, too, that stream connections are much easier to > reason about than asynchronous communication. Thus code built on > streams is far less vulnerable to timing bugs. > > At last a prince has come to awaken the sleeping beauty of stream > connections. In Go (Pike again) we have a widely accepted programming > language that can fully exploit them, "[w]hich is, y'know, what Unix > is 'for'." > > (If you wish, you may read "process" above to include threads, but > I'll stay out of that.) > > Doug > -- - Tom --000000000000bece3f05c8aace67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= lways believed that fork() was the very essence of the beauty of UNIX. So s= imple, yet so powerful.=C2=A0 And it is far simpler than its predecessor on= Genie, which looked a lot more like spawn().

With fork, the child inherits properties which=C2=A0ma= y not have existed when the code was written, so it's much easier to re= ason about the behavior of sub-processes.=C2=A0 Fork made writing the shell= and pipelines much more obvious.

Today we know that threads and shared mutable memory are a reall= y bad idea, it's just that the hardware gave us no alternatives. I clai= m UNIX is directly responsible for the existence of MMUs in microprocessors= .=C2=A0 What if CPU designers would=C2=A0add facilities to directly impleme= nt inter-process or inter-processor messaging?=C2=A0 Sadly, there has to be= a dominant software paradigm for the hardware guys to target, so there'= ;s a nasty chicken and egg problem.=C2=A0 Imagine if the Erlang model of di= stributed systems had taken off.=C2=A0 Go gets us part of the way there, bu= t cross-machine messaging is still a mess.

On Tue, Aug 3, 2021 at 8:02= AM Douglas McIlroy <do= uglas.mcilroy@dartmouth.edu> wrote:
> fork() is a great model for a single-thread= ed text processing pipeline to do
> automated typesetting.=C2=A0 (More generally, anything that is a strai= ghtforward
>=C2=A0 composition of filter/transform stages.)=C2=A0 Which is, y'k= now, what Unix is *for*.

> It's not so great for a responsive GUI in front of a multi-functio= n interactive=C2=A0 program.

"Single-threaded" is not a term I would apply to multiple process= es in
a=C2=A0 pipeline. If you mean a single track of data flow, fine, but the fact that that's a prevalent configuration of cooperating processes in<= br> Unix is an artifact of shell syntax, not an inherent property of
pipe-style IPC. The cooperating processes in Rob Pike's 20th century window systems and screen editors, for example, worked smoothly
without interrupts or events - only stream connections. I see no
abstract distinction between these programs and=C2=A0 "stuff people pl= ay
with on their phones."

It bears repeating, too, that stream connections are much easier to
reason about than asynchronous communication. Thus code built on
streams is far less vulnerable to timing bugs.

At last a prince has come to awaken the sleeping beauty of stream
connections. In=C2=A0 Go (Pike again) we have a widely accepted programming=
language that can fully exploit them, "[w]hich is, y'know, what Un= ix
is 'for'."

(If you wish, you may read "process" above to include threads, bu= t
I'll stay out of that.)

Doug


--
- Tom
--000000000000bece3f05c8aace67--