6 Aug
2021
6 Aug
'21
2:55 a.m.
On Wed, Aug 4, 2021 at 6:51 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Wed, Aug 04, 2021 at 06:41:08PM -0400, John Cowan
wrote:
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.
On Wed, Aug 4, 2021 at 6:02 PM Larry McVoy
<lm(a)mcvoy.com> wrote:
new
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 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.