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=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1138 invoked from network); 2 Aug 2021 18:24:45 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2021 18:24:45 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 123EC9CA98; Tue, 3 Aug 2021 04:24:44 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3C60C9CA63; Tue, 3 Aug 2021 04:24:20 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="BOOVwJjM"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 82A889CA63; Tue, 3 Aug 2021 04:24:18 +1000 (AEST) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by minnie.tuhs.org (Postfix) with ESMTPS id 5565E9CA60 for ; Tue, 3 Aug 2021 04:24:17 +1000 (AEST) Received: by mail-qt1-f170.google.com with SMTP id a19so12295867qtx.1 for ; Mon, 02 Aug 2021 11:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VAt7QxGpyMATUg6GbNri2yvkieQaLdrkS6eHT82E6VA=; b=BOOVwJjMbAqwbg2mOnEvlmjeJsrz0NoDgLFKRt+H09rRMvjYmlzogv3YVqFVcaL+hH m/rGyupiCoBCD8ew1sWPAs1rA9qp4eXIh4dDB4VNopC/ox/ktLZ7ghNjFo6hTwTK6vZW E+POENcH0SvfzzVFX0ZX73cl97Efx1+JrzCMsPzi+JVzojoSHtVeXAVB/X6tEyoKwu3m qef/UcgK24BH9g6xvxyN+Sjo3kJfl0MAqOtGomnCdT8L+GVgUb0BroZz24ZSGmGuOYLU dqhLGZ0XBF9BFh2p05poezSGeg6oBU9IgPfVm9Yn1iRNI6vJkdtIAUF8szybfDQgwvib Tn/A== 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=VAt7QxGpyMATUg6GbNri2yvkieQaLdrkS6eHT82E6VA=; b=Y9nJGbAMRAxGUh9p/Q/HzyqeArmXUO50+acZAbZha4lhUWP/6jHh1Hu10FCg//5tk1 Nfnc12fCluTPXcmI4JI9WFtL4O7eNQf9gOjfni5xsZBk3bLkZPIzr2Phy94ndf+ok6Ik h2Tla8PRLNLXIF3FqDIU6TZPV6Il+ttIXZDeoUc5ZIFtABmSrcWUu58Mtgsey/X5zBJ8 BN7qU97ctmiMTrpGVIu7J17XAVRYzFzSO2o+NTs50idSxXw3ioEbmT7V2GuWvJZ8dOtX 9ZJmd9QL0WjD5M94TFylf04MsUcV+vkMHTW7Tu6Z8VxtYoeyzMFMax4lYZ1wDGvDK9yZ BfcA== X-Gm-Message-State: AOAM532NnwxJZTVZBrdYqhG+k5zJ9WLOgXwUTa1QR8h1ol6qKSj2odbQ Ki7irb66MxzA0mRBPTkSo2dvRuN8uuNAe9VCEM2FGg== X-Google-Smtp-Source: ABdhPJwjiQAPddNK+TJThuUnQa6J9bPdojo1hj0zf00Lr6FB6K5/csgEWbxppqQsXyCg5Q2Ei0sA8ngyyt/NiGk4Jzk= X-Received: by 2002:ac8:5b8a:: with SMTP id a10mr15122366qta.235.1627928656264; Mon, 02 Aug 2021 11:24:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 2 Aug 2021 12:24:05 -0600 Message-ID: To: Adam Thornton Content-Type: multipart/alternative; boundary="00000000000046d42b05c897ad33" 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: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000046d42b05c897ad33 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 2, 2021 at 12:16 PM Adam Thornton wrote: > It's a measure of Unix having been wounded by its own success. > > 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*. > fork() dates from a time that demand paging wasn't a thing. Processes were as cheap as it got. There were no threads. All the different variations on a theme on fork() since then have been to either make threads super cheap to create, to optimize the exec case (which already has been discussed a bit:), and/or to control what the new process inherits. It's not so great for a responsive GUI in front of a multi-function > interactive program. > > These days, the vast majority of Unix applications are "stuff people play > with on their phones." > Ah, a thread-heavy environment that's not all that exec intensive (but that's complicated enough you can no longer safely do a naive fork/exec when you need to)... But mostly, it's threads. Warner > Adam > > On Mon, Aug 2, 2021 at 7:59 AM Theodore Ts'o wrote: > >> On Sun, Aug 01, 2021 at 10:42:53PM -0400, Douglas McIlroy wrote: >> > > spawn() beats fork()[;] fork() should be deprecated >> > >> > Spawn is a further complication of exec, which tells what signals and >> > file descriptors to inherit in addition to what arguments and >> > environment variables to pass. >> > >> > Fork has a place. For example, Program 1 in >> > www.cs.dartmouth.edu/~doug/sieve/sieve.pdf forks like crazy and never >> > execs. To use spawn, the program would have to be split in three (or >> > be passed a switch setting). >> > >> > While you may dismiss Program 1 as merely a neat demo, the same idea >> > applies in parallelizing code for use in a multiprocessor world. >> >> It's certainly clear that some kind of primitive is needed to create >> new threads. An open question is whether if there exists some kind of >> "new thread" primitve plus either spawn(2) or some kind of "create a >> child process and then then frob like crazy using 'echo XXX > >> /proc//'" whether there still is a need for a >> fork(2) system call. >> >> Obviously, as soon as we start going down this path, we're deviated >> quite strongly from the "radical simplicity" of Unix Version 7 that >> people have accused modern systems (whether they be Linux or FreeBSD) >> of lacking. It's rather interesting that we haven't heard complaints >> about how people who dare to try come up with new API's are somehow >> traitors to "The Unix Philosphy" that we've seen on other threads. :-) >> >> - Ted >> > --00000000000046d42b05c897ad33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 2, 2021 at 12:16 PM Adam = Thornton <athornton@gmail.com= > wrote:
It's a measure of Unix having been wounded by its own= success.

fork() is a great model for a single-thr= eaded text processing pipeline to do automated typesetting.=C2=A0 (More gen= erally, anything that is a straightforward composition of filter/transform = stages.)=C2=A0 Which is, y'know, what Unix is *for*.

fork() dates from a time that demand paging wasn&= #39;t a thing. Processes were as cheap as it got. There were no threads.

All the different variations on a theme on fork() si= nce then have been to either make threads super cheap to create, to optimiz= e the exec case (which already has been discussed a bit:), and/or to contro= l what the new process inherits.

It's not so great for= a responsive GUI in front of a multi-function interactive program.

These days, the vast majority of Unix applications are &q= uot;stuff people play with on their phones."
<= div>
Ah, a thread-heavy environment that's not all that e= xec intensive (but that's complicated enough you can no longer safely d= o a naive fork/exec when you need to)...

But mostl= y, it's threads.

Warner
=C2=A0
=
Ada= m

On Mon, Aug 2, 2021 at 7:59 AM Theodore Ts'o <tytso@mit.edu> wrote:
On Sun, Aug 01, 2021 a= t 10:42:53PM -0400, Douglas McIlroy wrote:
> > spawn() beats fork()[;] fork() should be deprecated
>
> Spawn is a further complication of exec, which tells what signals and<= br> > file descriptors to inherit in addition to what arguments and
> environment variables to pass.
>
> Fork has a place. For example, Program 1 in
> www.cs.dartmouth.edu/~doug/sieve/sieve.pdf= forks like crazy and never
> execs. To use spawn, the program would have to be split in three (or > be passed a switch setting).
>
> While you may dismiss Program 1 as merely a neat demo, the same idea > applies in parallelizing code for use in a multiprocessor world.

It's certainly clear that some kind of primitive is needed to create new threads.=C2=A0 An open question is whether if there exists some kind of=
"new thread" primitve plus either spawn(2) or some kind of "= create a
child process and then then frob like crazy using 'echo XXX >
/proc/<pid>/<magic files>'" whether there still is a n= eed for a
fork(2) system call.

Obviously, as soon as we start going down this path, we're deviated
quite strongly from the "radical simplicity" of Unix Version 7 th= at
people have accused modern systems (whether they be Linux or FreeBSD)
of lacking.=C2=A0 It's rather interesting that we haven't heard com= plaints
about how people who dare to try come up with new API's are somehow
traitors to "The Unix Philosphy" that we've seen on other thr= eads.=C2=A0 :-)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 - Ted
--00000000000046d42b05c897ad33--