<div dir="ltr"><div dir="ltr">On Wed, Aug 4, 2021 at 6:51 PM Larry McVoy <<a href="mailto:lm@mcvoy.com">lm@mcvoy.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 04, 2021 at 06:41:08PM -0400, John Cowan wrote:<br>
> On Wed, Aug 4, 2021 at 6:02 PM Larry McVoy <<a href="mailto:lm@mcvoy.com" target="_blank">lm@mcvoy.com</a>> wrote:<br>> >      A computer is a state machine. Threads are for people who can't<br>
> >      program state machines.<br>
> ><br>
> >      Alan Cox<br>
> <br>
> Orly?  Try embedding an LL(1) parser in an event loop that gives you a new<br>
> event every time a block is read off the disk.<br>
> <br>
> Event loops are just manual CPS transformations of coroutines -- but why do<br>
> the transformation manually instead of having your compiler do it for you?<br>
<br>
The counter to this is Solaris tried to allocate a thread for each 8K page<br>
on it's way to disk.  The thread stack was 16K.  This model, while seen as<br>
ever so elegant, means that 2/3rds of main memory were thread stacks.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Sometimes threads make sense, there they did not.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>        - Dan C.</div><div><br></div></div></div>