Re: [TUHS] Threads vs... not

[Steffen Nurpmeso <steffen@sdaoden.eu>]

John Cowan wrote in
 <CAD2gp_SH5qt2G0oyHeDYnQbjmHeejz9A8FJhCvBFOKq21aAVkg@mail.gmail.com>:
 |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.

Well i am just too old and lazy to really dig into the
asynchronous hype you see "everywhere".  I know just for fun i did
some MacOS Audio thing around 2009/10 (when i bought the single
Apple i once wanted), nothing but a simple OggVorbis player
(because Quicktime just did not like free Audio, and because i was
interested), and those callbacks i had to deal with just drove me
insane.  The Linux Jack Audio Server also does that, i think.
I do not understand.  The CPU usage was just _grazy_, even though
i used the biggest buffers i could use (iirc).  I mean, i could
drive audio play and recording side-by-side (with programming
work) on a Cyrix 166+ with a 3 MB/sec (30 MB/sec with caching,
there was some I/O test on Linux, forgotten the name) hard disk on
FreeBSD 4.7 or what, it was nice(1)d, but other than that, and
i think under 1 or 3 percent CPU.  That is how it has to be!

And not to forget most async and maybe even many coroutine things
just internally base on threads, i think OpenSSL for example does,
so what looks so cheap and "tickless" is in effect a tremendous
monster.  I hope they at least use pools.  And that the pools do
not leak resources to wherever.
No, by chance, i am simple-minded and drove non-blocking event
loops, which nicely bundled I/O events and gave me timers for
free.  This scaled wonderful.  And for multi-core and super
efficiency it scales easily, too: either by having worker threads
(or sandboxed, isolated processes), picked out of a pool, doing
work as it happens, or maybe, today, scaled by X different event
loops.  (Like, for networking, having one accepting new
connections, and several others handling them.)  But this seems so
"hyper", i wonder whether any of the actually used "super
servers", say postfix, dovecot, exim, postfix, *sql, apache,
nginx, let me add lighttpd now that i said postfix, as it works so
nice, uses _so_ much scaling, in the actual everyday work.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)