<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:large"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 6, 2021 at 10:20 AM Steffen Nurpmeso <<a href="mailto:steffen@sdaoden.eu">steffen@sdaoden.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bakul Shah wrote in<br>
 <<a href="mailto:74E8349E-95A4-40C9-B429-11A4E396BE12@iitbombay.org" target="_blank">74E8349E-95A4-40C9-B429-11A4E396BE12@iitbombay.org</a>>:<br>
 |It was efficient but the control flow got<br>
 |quite messy as effectively my code had to do explicit<br>
 |continuation passing. <br>
<br>
Only twenty years ago but i was under the impression that i got<br>
good (better) performance by having a single event loop object<br>
(thread) doing the select(2) aka the OS interaction, as the driver<br>
under the hood of an IOEvent thing, which then were emitted.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">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.</div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">After all, the interface to all modern operating systems is as a coroutine: when we call read() we give up control to the kernel, who does the read for us and delivers it to a buffer in our space, then surrenders control back.  (How it looks from inside the kernel is another story.)  Only when we request signal handling does the kernel actually interrupt the ordered flow within our program, but the restrictions on what a signal handler can do in Posix are so many that it's hardly safe to do more than set a flag to be polled later or to do a longjmp() to invoke a continuation further up the stack.</div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large">Historic operating systems worked quite differently: they had the equivalent of signals that meant "disk block has been read" (use the buffer, and fast, before the OS starts to write the next block into it) and "disk block has been written" (the buffer is available for reuse).  And programming for them was, in someone's memorable phrase, like moving dead whales along the beach by kicking them.</div><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><br></div></div></div>