6 Aug
2021
6 Aug
'21
5:12 p.m.
John Cowan wrote in
<CAD2gp_SH5qt2G0oyHeDYnQbjmHeejz9A8FJhCvBFOKq21aAVkg(a)mail.gmail.com>:
|On Fri, Aug 6, 2021 at 10:20 AM Steffen Nurpmeso <steffen(a)sdaoden.eu> \
|wrote:
|> Bakul Shah wrote in
|> <74E8349E-95A4-40C9-B429-11A4E396BE12(a)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)