On Wed, Aug 4, 2021 at 6:02 PM Larry McVoy <lm(a)mcvoy.com> wrote: Orly? Try embedding an LL(1) parser in an event loop that gives you a new event every time a block is read off the disk. Event loops are just manual CPS transformations of coroutines -- but why do the transformation manually instead of having your compiler do it for you?

On Wed, Aug 4, 2021 at 6:51 PM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: Right. The problem is too often people have a hammer and make everything a nail. Or they have an electric screwdriver and then try to use if for everything. The trick is to teach good taste and when certain solutions make more sense than others. Allocating a thread for every page being sent to disk, or needing 120 threads for a simple application -- somebody missed the boat. Funny, used to deliver nails in kegs. Hit with a hammer - wood fastened. Somebody develops a screw system. A 'better fastener.' Indeed it does work great for >>some jobs<< but not all. Frankly that sucks for framing. What do you see at any real job site. Not screws but a pneumatic hammer and nail cartridges? Changed the deliver system from key and forcing somebody to swing the hammer. Lesson learned to *use the proper tool *or update the tool if the Kids these days ... get off my lawn... Clem

Bakul Shah wrote in &lt;74E8349E-95A4-40C9-B429-11A4E396BE12(a)iitbombay.org&gt;rg>: |On Aug 4, 2021, at 2:48 PM, Lawrence Stewart &lt;stewart(a)serissa.com&gt; wrote: |> |> What do folks think about event-driven programming as a substitute \ |> for threads in UI and process control settings? | |The equivalence here is with coroutines (sometimes called |green-threads), not true threads. True threads can take |advantage of multiple cores. Your event-driven program won't |benefit from multiple cores. | |> I wrote the service processor code for the Sicortex Machines using \ |> libevent.a and I thought it was very lightweight and fairly easy \ |> to think about. (This was a thing running on ucLinux on a tiny 16 \ |> MB coldfire that managed the consoles and power supplies and temp \ |> sensors and JTAG access and booting and so forth.) | |I wrote the RealNetworks media server code using an |event-driven model. It was efficient but the control flow got |quite messy as effectively my code had to do explicit |continuation passing. Given that each media stream was |independent of other streams, a thread based model was far |simpler. That is what a colleague did to test the server |code! 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. These then dispatched to worker threads, or not. It may be different today with those highly refined mechanisms poll, epoll, kqueue. It may anyway be different with whatever operating system specific things, for example FreeBSD had or has some network ring where user and kernel space could simply exchange buffers, ?, well i remember it was written by an Italien (Professor?) living in Pisa, in sight of the lopsided tower. And then the audioring technology Creative Labs shipped with X-Fi ~2005. --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)

John Cowan wrote in &lt;CAD2gp_SH5qt2G0oyHeDYnQbjmHeejz9A8FJhCvBFOKq21aAVkg(a)mail.gmail.com&gt;om>: |On Fri, Aug 6, 2021 at 10:20 AM Steffen Nurpmeso &lt;steffen(a)sdaoden.eu&gt; \ |wrote: |> Bakul Shah wrote in |> &lt;74E8349E-95A4-40C9-B429-11A4E396BE12(a)iitbombay.org&gt;rg>: |>|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)