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=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3254 invoked from network); 6 Aug 2021 14:43:55 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Aug 2021 14:43:55 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id C92899CAF5; Sat, 7 Aug 2021 00:43:52 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id F37E49C9E8; Sat, 7 Aug 2021 00:43:34 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=ccil-org.20150623.gappssmtp.com header.i=@ccil-org.20150623.gappssmtp.com header.b="pI/fbQK4"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 4CAFA9C9E8; Sat, 7 Aug 2021 00:43:31 +1000 (AEST) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by minnie.tuhs.org (Postfix) with ESMTPS id 2FB029C9E0 for ; Sat, 7 Aug 2021 00:43:30 +1000 (AEST) Received: by mail-qt1-f176.google.com with SMTP id d9so6577349qty.12 for ; Fri, 06 Aug 2021 07:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LswiWxH8UwVbCIfQ+JtDngi9uenfUwozfVuKoEpS7vg=; b=pI/fbQK4uY3REtIXiDDv4Fo/eM5rrh29hNaan17zn1RrjKsxgr7VQu7ThHPdj/5jtu EJwrVapN1O/mMYZP7UHLKRPvyJlZCoJXUzQrQYXTQeKoYBZ4+6avwWnkWz0aahWiKlX1 VuM2ztV8bmjFvtx82mtgL/d3X2QHhu9Ut2pPzJ/F4vIcoQUGSRASuUbASZF9Kj3G5d0q zf5TYDITZD4M7RbCQV2AmasXiq25WqKqKQTNyHjwwRHYow2/MQZ1pHT7tpPrc539Ykho RZOewVnK63NyRFM5n+WPwCssTC8zGAZGc353jYwveva8T3m6hG/ppRJpA4F8wxtVy+O6 gTmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LswiWxH8UwVbCIfQ+JtDngi9uenfUwozfVuKoEpS7vg=; b=bgZeO3QbOd2u/tfs6RYYB75DNARE3V44yr3kiL4SpQH7HXP2rlcNVTt2eNWfzARppX HVx4hBaCvYo1QdJphBSan+8gscg3BBzUG4bfqDHwQn8d7tEi8N94SFsHClYG92Q4zpvo EGq12nVEKgh+sp2Al0NCnDgRDzJnvs82qijdPAFXJX5Dd12wotqFeS1pm9578kwzQdHR ynDAKVblIQIUR6yIsFTvd8cpOpEj4XtjkjmG2exqPurYOW2zEzrrJYNUK0Or9PWn5lGs KsEf2wHpky5KZ+MJ+FO70AD4j/ONblA4uHioJ2XEj6NnR/2N1z3eqKBVR/8RQOIaArTj Us4A== X-Gm-Message-State: AOAM530WvaJEe8nvER6joegCCnzXsy64c06EJ8q0TdjKP5coQyLAF4ji Iaw/WCIfj08JfhWI6k1vgQaOBWsX7gV1xqm+YZ8HSQ== X-Google-Smtp-Source: ABdhPJyh9pJRl3on+caMZHe+LWDl5IrgTXqIhNguXkcrew5NDXeg+T0Rb1PmpVfD7PKQYlX2b5Pm0INuyZapJ3uaprI= X-Received: by 2002:ac8:7f01:: with SMTP id f1mr9392627qtk.362.1628261009007; Fri, 06 Aug 2021 07:43:29 -0700 (PDT) MIME-Version: 1.0 References: <74E8349E-95A4-40C9-B429-11A4E396BE12@iitbombay.org> <20210806141924.O2Y1R%steffen@sdaoden.eu> In-Reply-To: <20210806141924.O2Y1R%steffen@sdaoden.eu> From: John Cowan Date: Fri, 6 Aug 2021 10:43:17 -0400 Message-ID: To: Bakul Shah , Lawrence Stewart , TUHS main list Content-Type: multipart/alternative; boundary="0000000000000b417105c8e50f1e" 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000000b417105c8e50f1e Content-Type: text/plain; charset="UTF-8" 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. 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. 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. --0000000000000b417105c8e50f1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 6, 20= 21 at 10:20 AM Steffen Nurpmeso <s= teffen@sdaoden.eu> wrote:
Bakul Shah wrote in
=C2=A0<74E8349E-95A4-40C9-B429-11A4E396BE12@iitbombay.org>:
=C2=A0|It was efficient but the control flow got
=C2=A0|quite messy as effectively my code had to do explicit
=C2=A0|continuation passing.=C2=A0

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 violen= t agreement: you get more performance with an event loop.=C2=A0 So perhaps = Cox's claim is true after all: threads are for programmers who can'= t deal with events.=C2=A0 And then my claim is that at a certain not-very-h= igh level of complexity no one can deal with events.

After all, the interface to al= l modern operating systems is as a coroutine: when we call read() we give u= p control to the kernel, who does the read for us and delivers it to a buff= er in our space, then surrenders control back.=C2=A0 (How it looks from ins= ide the kernel is another story.) Only when we request signal handling doe= s the kernel actually interrupt the ordered flow within our program, but th= e 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.

Historic operating syst= ems 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 w= ritten" (the buffer is available for reuse).=C2=A0 And programming for= them was, in someone's memorable phrase, like moving dead whales along= the beach by kicking them.

=
--0000000000000b417105c8e50f1e--