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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6929 invoked from network); 6 Aug 2021 00:56:36 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2021 00:56:36 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5855B9CAF8; Fri, 6 Aug 2021 10:56:34 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 10F699C9E8; Fri, 6 Aug 2021 10:55:58 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="b5lLc0k+"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 07DD69C9E8; Fri, 6 Aug 2021 10:55:56 +1000 (AEST) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 326C59C9E0 for ; Fri, 6 Aug 2021 10:55:55 +1000 (AEST) Received: by mail-oi1-f180.google.com with SMTP id u10so9876561oiw.4 for ; Thu, 05 Aug 2021 17:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eBBeEOXUm9CZS32NP2SNGk8WsZTzBGd6hMw6dCyaVf4=; b=b5lLc0k+VrJ0N8YF1GMSJ1q0vys6QhRuUdF6BKv9B170pGTRn3qqPdpzUACMSjJpUG CgqLB5Gaod8XlFwd167L9jMUJtcxHbdxCDFNrf9nOebxb3kDlfUAtKWtTiLGHlQY2+T8 u2o2nA0ZQBc/ITt9y7ERbBfFqPunaFbgLK7Lx+9rQFdCN8/aieka56mJ+TJlSIUZe3Rd HJHAFPh4AZBaI+4bDcvN64qBrp+XTSiKy2iVk/4YGFXLkmww2GIUfUFMBbXrV4WBbFIg gH8bI6pri1BADkU/l2qGXLk6ixuvRAfhbQWQqz1Rtb6lsoUh5PSBYbOVBFFqhLhssnNf b7OA== 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=eBBeEOXUm9CZS32NP2SNGk8WsZTzBGd6hMw6dCyaVf4=; b=QdxgTj6/pORBhkUQSj5aOr4u8u9acZ6iwbQWkt1MHguuIP+1q1sHtuXupQcLpptryw M4tS72KePTtpzZkOid7B1Z7gANTBaapuOKq+rXUucKzcvgnOKrMG9Ak4qc4I0N2J/PHb Yw1rcPgRxKVeDAqmSJTD1cGjXXjTFzn+SHbVtcmweo1IXctU7bRiOIOWbHWEvt9aJtuy 6ct6Vnri+qWjkuOPnj0hKaqgcoJByf7cZocqkdn4PDvpcNa7Y2RoUBZHnnMNSdwy2u2l iHY5oMhh/Aasa6clcOlP4LeW8yeEc+P8pDeI6Dwha15VfHCQD0gO2Uz/m1GXC+G7n2Is nClg== X-Gm-Message-State: AOAM5316oBCcQ8oQtp0KywsQcLTMmM0MhFTLGT7kSA0aURXg5ag3zRgf sNx9QIlLEWFZTL15u/HdcrP1rj3DtSL21XchkcrJ9HPTmAk= X-Google-Smtp-Source: ABdhPJzKJvvRj6GJH33/SMOdGET10emaNam5M8oej38Qc+76NJTkb/ep/naeoC3kwgXx6JlNuLBnvoJ69dhO8zbvxSA= X-Received: by 2002:aca:ea54:: with SMTP id i81mr3012415oih.174.1628211354380; Thu, 05 Aug 2021 17:55:54 -0700 (PDT) MIME-Version: 1.0 References: <20210804220208.GK9074@mcvoy.com> <20210804225107.GL9074@mcvoy.com> In-Reply-To: <20210804225107.GL9074@mcvoy.com> From: Dan Cross Date: Thu, 5 Aug 2021 20:55:18 -0400 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="00000000000065b14805c8d97fb6" Subject: Re: [TUHS] Threads vs... not 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" --00000000000065b14805c8d97fb6 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 4, 2021 at 6:51 PM Larry McVoy wrote: > On Wed, Aug 04, 2021 at 06:41:08PM -0400, John Cowan wrote: > > On Wed, Aug 4, 2021 at 6:02 PM Larry McVoy wrote: > > > A computer is a state machine. Threads are for people who can't > > > program state machines. > > > > > > Alan Cox > > > > Orly? Try embedding an LL(1) parser in an event loop that gives you a > new > > event every time a block is read off the disk. > > > > Event loops are just manual CPS transformations of coroutines -- but why > do > > the transformation manually instead of having your compiler do it for > you? > > The counter to this is Solaris tried to allocate a thread for each 8K page > on it's way to disk. The thread stack was 16K. This model, while seen as > ever so elegant, means that 2/3rds of main memory were thread stacks. > Honestly this sounds like a misapplication of threads. It makes more sense to me to have a small pool of workers working on a bounded queue or something. Sometimes threads make sense, there they did not. It strikes me that the Unix kernel we all know and love has been multithreaded since the early 1970s, when multiprogramming overlapped with IO was introduced; even in something as simple as 6th Edition, every process has a corresponding kernel thread and the fundamental mechanism to context switch from process $n$ to process $m$ is for n to trap into the kernel where it's running on n's kernel thread, invoke the scheduler to perform a thread switch to m's kernel thread, and then return to m's userspace. Various attempts at replacing multithreaded kernels with event-driven state machines have been proposed and tried, but in the end, I always come away with the sense that most of the time, when used judiciously, threads are wonderful concurrency primitives. - Dan C. --00000000000065b14805c8d97fb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 4, 2021 at 6:51 PM Larry McVo= y <lm@mcvoy.com> wrote:
=
lm@mcvoy.com> wrote:
> >=C2=A0 = =C2=A0 =C2=A0 A computer is a state machine. Threads are for people who can= 't
> >=C2=A0 =C2=A0 =C2=A0 program state machines.
> >
> >=C2=A0 =C2=A0 =C2=A0 Alan Cox
>
> Orly?=C2=A0 Try embedding an LL(1) parser in an event loop that gives = you a new
> event every time a block is read off the disk.
>
> Event loops are just manual CPS transformations of coroutines -- but w= hy do
> the transformation manually instead of having your compiler do it for = you?

The counter to this is Solaris tried to allocate a thread for each 8K page<= br> on it's way to disk.=C2=A0 The thread stack was 16K.=C2=A0 This model, = while seen as
ever so elegant, means that 2/3rds of main memory were thread stacks.

Honestly this sounds like a misapplication o= f threads. It makes more sense to me to have a small pool of workers workin= g on a=C2=A0bounded queue or something.

Sometimes threads make sense, there they did not.

It strikes me that the Unix kernel we all know and love has been mul= tithreaded since the early 1970s, when multiprogramming overlapped with IO = was introduced; even in something as simple as 6th Edition, every process h= as a corresponding kernel thread and the fundamental mechanism to context s= witch from process $n$ to process $m$ is for n to trap into the kernel wher= e it's running on n's kernel thread, invoke the scheduler to perfor= m a thread switch to m's kernel thread, and then return to m's user= space.

Various attempts at replacing multithreaded= kernels with event-driven state machines have been proposed and tried, but= in the end, I always come away with the sense that most of the time, when = used judiciously, threads are wonderful concurrency primitives.
<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--00000000000065b14805c8d97fb6--