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.