The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <>
To: John Cowan <>
Cc: Bakul Shah <>, TUHS main list <>
Subject: Re: [TUHS] Threads vs... not
Date: Fri, 06 Aug 2021 17:12:23 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

John Cowan wrote in
 |On Fri, Aug 6, 2021 at 10:20 AM Steffen Nurpmeso <> \
 |> Bakul Shah wrote in
 |>  <>:
 |>|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.

|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)

      reply	other threads:[~2021-08-06 15:12 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
2021-08-06 15:12       ` Steffen Nurpmeso [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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).