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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19955 invoked from network); 2 Jun 2020 19:24:02 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2020 19:24:02 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 95D609CAD7; Wed, 3 Jun 2020 05:24:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5C89E9CAD2; Wed, 3 Jun 2020 05:23:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="nzjrF3i4"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id CE06C9CAD2; Wed, 3 Jun 2020 05:23:47 +1000 (AEST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 44EB79C96B for ; Wed, 3 Jun 2020 05:23:47 +1000 (AEST) Received: by mail-qk1-f171.google.com with SMTP id c12so13666590qkk.13 for ; Tue, 02 Jun 2020 12:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tqucrIivIVSkgs2vpDBCeDM7S4tEwbEh/ouzVkspQNs=; b=nzjrF3i4lkneodo1RrmziKKJmrNc9ahRH3gNwZ/LNq0yMlA01qU6eloGAKfYF9vb1z cmu46kr73j6XayqurTHvLroW984BXwG5P/As94XUhXzIE329VRg1SZ+r4qw4y6FJNDC/ Id8P3ivIIqnkrXxixuvKoIntca8Ry8nxe4ZDw= 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:cc; bh=tqucrIivIVSkgs2vpDBCeDM7S4tEwbEh/ouzVkspQNs=; b=N698vraqQqHb4b424uJ1cMDgKuwDknKlcfyQ3MFepHnfW/Ah74cldYhE3new3YzfSl RDQ+sGV2kl5lTBLAVwVX9dM2EeN/M0bA/Kfv6CkXNQxYvZDa4wK+E7hJuHFeT4cyl/Ga VlrI8e67UedNl8Ud7N1lI4CNogJge1bl/jQxIy5xbQONm2jDItjZntnqi9yhPYBj1Xlb NRL67GZeJEOyf9XBMD5GAts7lIVDsQ7BaiMzB8fLPAWT7ucEegtHB5fMY6rGW0xSxuLM 3Wul9J1dVAPdLEFAKi3e/WAU6tn8djMzsMY9xaZWkb4YWL3DWCy8k2EvyDehnwTdiimS VRcw== X-Gm-Message-State: AOAM533lnzZNjJl8xNmIm8g2GW1bYRzBbQbT/9ivbGy3jalzruK1zpij qjaCx9+Rh/rNqPcnJWu13SgFIS0I6WICNuS2ZdxNPA== X-Google-Smtp-Source: ABdhPJyWZHFPYdVSBIGaZ8xzXQNac+uguFo+nP5pCeNNIAOOYd4J5zrYGyeQrBtPC3FfDNewGQzT7IeZ6MkRNJ3ZuCo= X-Received: by 2002:a05:620a:1321:: with SMTP id p1mr26549885qkj.476.1591125826294; Tue, 02 Jun 2020 12:23:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clem Cole Date: Tue, 2 Jun 2020 15:23:20 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="000000000000ab6b0c05a71ed996" Subject: Re: [TUHS] non-blocking IO 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: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000ab6b0c05a71ed996 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 2:58 PM Paul Winalski wrote: > I think that's a very good question. It's analogous to > record-oriented I/O vs. byte stream I/O. It's easy to build > record-oriented I/O on top of a byte stream, but it's a real bear to > do it the other way around. Similarly, it's easy to build synchronous > I/O on top of asynchronous I/O but the reverse ends up looking contrived. > Which was exactly the point I tried to make in the POSIX.4 discussions, but it does take more work in the basic housekeeping and you need a way to handle events and completions that are priority based, queued, and a few other details. As Doug said, they stayed away from some features (like messaging). async I/O was one of them. But as I said, Ken, Dennis and the rest of the crew did an amazing job with very little. --000000000000ab6b0c05a71ed996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 2, 2020 at 2:58 = PM Paul Winalski <paul.winalski@gmail.com> wrote:
I think that's a very good question.=C2= =A0 It's analogous to
record-oriented I/O vs. byte stream I/O.=C2=A0 It's easy to build
record-oriented I/O on top of a byte stream, but it's a real bear to do it the other way around.=C2=A0 Similarly, it's easy to build synchro= nous
I/O on top of asynchronous I/O but the reverse ends up looking contrived.
Which was exactly=C2=A0the point I tri= ed to make in the POSIX.4 discussions, but it does take more work in the ba= sic housekeeping and you need a way to handle events and completions that a= re priority based, queued, and a few other details.=C2=A0 =C2=A0As Doug sai= d, they stayed away from some features (like messaging).=C2=A0 =C2=A0async = I/O was one of them.=C2=A0

But as I said= , Ken, Dennis and the rest of the crew did an amazing job with very little.=

--000000000000ab6b0c05a71ed996--