From: John Cowan <cowan@ccil.org>
To: Bakul Shah <bakul@iitbombay.org>,
Lawrence Stewart <stewart@serissa.com>,
TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Threads vs... not
Date: Fri, 6 Aug 2021 10:43:17 -0400 [thread overview]
Message-ID: <CAD2gp_SH5qt2G0oyHeDYnQbjmHeejz9A8FJhCvBFOKq21aAVkg@mail.gmail.com> (raw)
In-Reply-To: <20210806141924.O2Y1R%steffen@sdaoden.eu>
[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]
On Fri, Aug 6, 2021 at 10:20 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> Bakul Shah wrote in
> <74E8349E-95A4-40C9-B429-11A4E396BE12@iitbombay.org>:
> |It was efficient but the control flow got
> |quite messy as effectively my code had to do explicit
> |continuation passing.
>
> Only twenty years ago but i was under the impression that i got
> good (better) performance by having a single event loop object
> (thread) doing the select(2) aka the OS interaction, as the driver
> under the hood of an IOEvent thing, which then were emitted.
>
It sounds like you are in violent agreement: you get more performance with
an event loop. So perhaps Cox's claim is true after all: threads are for
programmers who can't deal with events. And then my claim is that at a
certain not-very-high level of complexity no one can deal with events.
After all, the interface to all modern operating systems is as a coroutine:
when we call read() we give up control to the kernel, who does the read for
us and delivers it to a buffer in our space, then surrenders control back.
(How it looks from inside the kernel is another story.) Only when we
request signal handling does the kernel actually interrupt the ordered flow
within our program, but the restrictions on what a signal handler can do in
Posix are so many that it's hardly safe to do more than set a flag to be
polled later or to do a longjmp() to invoke a continuation further up the
stack.
Historic operating systems worked quite differently: they had the
equivalent of signals that meant "disk block has been read" (use the
buffer, and fast, before the OS starts to write the next block into it) and
"disk block has been written" (the buffer is available for reuse). And
programming for them was, in someone's memorable phrase, like moving dead
whales along the beach by kicking them.
[-- Attachment #2: Type: text/html, Size: 3052 bytes --]
next prev parent reply other threads:[~2021-08-06 14:43 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
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 [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD2gp_SH5qt2G0oyHeDYnQbjmHeejz9A8FJhCvBFOKq21aAVkg@mail.gmail.com \
--to=cowan@ccil.org \
--cc=bakul@iitbombay.org \
--cc=stewart@serissa.com \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).