From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7371 invoked from network); 6 Aug 2021 15:12:57 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2021 15:12:57 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DFC8D9CB08; Sat, 7 Aug 2021 01:12:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 547FD9C9E8; Sat, 7 Aug 2021 01:12:31 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 50FDA9C9E8; Sat, 7 Aug 2021 01:12:29 +1000 (AEST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by minnie.tuhs.org (Postfix) with ESMTPS id 0C7009C9E0 for ; Sat, 7 Aug 2021 01:12:28 +1000 (AEST) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id 86C4B16056; Fri, 6 Aug 2021 17:12:25 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 5C3D8777; Fri, 6 Aug 2021 17:12:23 +0200 (CEST) Date: Fri, 06 Aug 2021 17:12:23 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: John Cowan Message-ID: <20210806151223._GD-D%steffen@sdaoden.eu> In-Reply-To: References: <74E8349E-95A4-40C9-B429-11A4E396BE12@iitbombay.org> <20210806141924.O2Y1R%steffen@sdaoden.eu> Mail-Followup-To: John Cowan , Bakul Shah , Lawrence Stewart , TUHS main list User-Agent: s-nail v14.9.22-173-g196623ce38 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Subject: Re: [TUHS] Threads vs... not X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bakul Shah , TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" John Cowan wrote in : |On Fri, Aug 6, 2021 at 10:20 AM Steffen Nurpmeso \ |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)