The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Cross <>
To: Larry McVoy <>
Cc: TUHS main list <>
Subject: Re: [TUHS] Threads vs... not
Date: Thu, 5 Aug 2021 20:55:18 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

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

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

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.

[-- Attachment #2: Type: text/html, Size: 2550 bytes --]

  parent reply	other threads:[~2021-08-06  0:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 21:48 Lawrence Stewart
2021-08-04 22:02 ` Larry McVoy
2021-08-04 22:41   ` John Cowan
2021-08-04 22:51     ` Larry McVoy
2021-08-05 20:32       ` Clem Cole
2021-08-06  0:55       ` Dan Cross [this message]
2021-08-04 22:13 ` Anthony Martin
2021-08-05 23:02 ` Bakul Shah
2021-08-06 14:19   ` Steffen Nurpmeso
2021-08-06 14:43     ` John Cowan
2021-08-06 15:12       ` Steffen Nurpmeso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).