On Wed, Aug 4, 2021 at 6:51 PM Larry McVoy <lm@mcvoy.com> 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 <lm@mcvoy.com> 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.