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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13119 invoked from network); 2 Jun 2020 18:24:56 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2020 18:24:56 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DDAD29CAEA; Wed, 3 Jun 2020 04:24:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A13449CAD2; Wed, 3 Jun 2020 04:24:38 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="HUc/DKsr"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 0859B9CAD2; Wed, 3 Jun 2020 04:24:37 +1000 (AEST) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by minnie.tuhs.org (Postfix) with ESMTPS id 666909C96B for ; Wed, 3 Jun 2020 04:24:36 +1000 (AEST) Received: by mail-qt1-f175.google.com with SMTP id c12so11410240qtq.11 for ; Tue, 02 Jun 2020 11:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qeMoEzKrq8sdrHfqYfcLbdL22vWpDUfZ1F3ITkoVx6c=; b=HUc/DKsr//dDhRwFv7kZ2Os4Vy9uMtjDVFy+EKU+P2X6fhJFSw8xa8pMcqP5XLLL2X 1eHer6bUrJfZFuD09t+cTKxocqE5rFvAiuWPnSb0KugDOyM6mDuk2De8nybF3xQK0W2O 0N0xEcIJUyhrWM7MKK0UU2RR4BZlVkojdzPG+snRYWK5nOCgLOv6TIIJrm1r8g0n8sTA hmeQJgIyVv1yRXEI9K1XhGN6+4eFXTwBCnWFk3JurQBCKt8RrwEgG2ZNRwiJXF+GihRU gNZNxVlWu+ejgO1RAbhqUWjuOO5QdxSCivTsjBMzF90Brb0olTuENBBofsJhJaAo41Cu z5XA== 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=qeMoEzKrq8sdrHfqYfcLbdL22vWpDUfZ1F3ITkoVx6c=; b=lSXLyqh/WxltUDoRF9ceNK27E8mwpDDpOGBTBSjnItr0g9TSv48jHmqSbDiGslGyEw pZZZCzF/o/qNP1cw9HLcfLbImY0TZVUfsgPijD4+rVKMPYVMOK8iFWbdO4Rqwnn9LycH q7YRdHh9fw4O3UzB6BPeJQvCXESrojX4qtqmro+DuEhoqs5J+nEmShsLrW7hPcsS+lhA lWbeNJ98OfE2R4XI2KYyaF3oj8HqtoUcIsz+r7rTz9swjaZorq0AtIqHtiU9dVho6j8D 4W1LC1y0Zhfd3M7NTFfkyxLDg4eRf6NXaSc0Tm7rpc4di9zIiw/TlT1j0PaDMV35s5Lu IeeQ== X-Gm-Message-State: AOAM531CdiC5G5exLNaupJZUGmMTi9weLkGkw6BNxTK7U3xA42SRl/Vp kcGxWm63pSnXyPKhtJDmnL7vSIIvnWFqpLA8i8A= X-Google-Smtp-Source: ABdhPJx6gxytXr/U1710JBidOkMOQU7MzThv6w43R/+KpAB3NTbl1IOFl9AMuZ/fdtJKRYohANzqzCH8XqMWIIn0pzQ= X-Received: by 2002:ac8:2fa5:: with SMTP id l34mr27966836qta.46.1591122275554; Tue, 02 Jun 2020 11:24:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Cross Date: Tue, 2 Jun 2020 14:23:59 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="0000000000000758e705a71e0604" 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" --0000000000000758e705a71e0604 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 1:47 PM Paul Winalski wrote: > The operating systems that I cut my teeth on (OS/360, DOS/360, > VAX/VMS) all had basic I/O system calls that were non-blocking. > Blocking I/O calls were all built on top of that framework. I thus > found it curious that Unix took the opposite tack, and non-blocking > I/O was an afterthought. > > So I'm curious as to what the rationale was for Unix to have been > designed with basic I/O being blocking rather than asynchronous. > Especially that non-blocking I/O primitives were the norm for OSes in > those days. Doug addressed this, albeit in an oblique manner, on this list back in 2015: https://minnie.tuhs.org/pipermail/tuhs/2015-September/007509.html Quoting him: """ Unix was what the authors wanted for a productive computing environment, not a bag of everything they thought somebody somewhere might want. One objective, perhaps subliminal originally, was to make program behavior easy to reason about. Thus pipes were accepted into research Unix, but more general (and unruly) IPC mechanisms such as messages and events never were. The infrastructure had to be asynchronous. The whole point was to surmount that difficult model and keep everyday programming simple. User visibility of asynchrony was held to a minimum: fork(), signal(), wait(). Signal() was there first and foremost to support SIGKILL; it did not purport to provide a sound basis for asynchronous IPC. The complexity of sigaction() is evidence that asynchrony remains untamed 40 years on. """ My response at the time was to question whether asynchrony itself remains untamed, as Doug put it, or if rather it has proved difficult to retrofit asynchrony onto a system designed around fundamentally synchronous primitives? - Dan C. --0000000000000758e705a71e0604 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue,= Jun 2, 2020 at 1:47 PM Paul Winalski <paul.winalski@gmail.com> wrote:
The operating s= ystems that I cut my teeth on (OS/360, DOS/360,
VAX/VMS) all had basic I/O system calls that were non-blocking.
Blocking I/O calls were all built on top of that framework.=C2=A0 I thus found it curious that Unix took the opposite tack, and non-blocking
I/O was an afterthought.

So I'm curious as to what the rationale was for Unix to have been
designed with basic I/O being blocking rather than asynchronous.
Especially that non-blocking I/O primitives were the norm for OSes in
those days.

Doug addressed this, albeit in = an oblique manner, on this list back in 2015:=C2=A0https://minnie.tuhs.o= rg/pipermail/tuhs/2015-September/007509.html

Q= uoting him:

"""
Unix was = what the authors wanted for a productive computing environment,
not a ba= g of everything they thought somebody somewhere might want.
One objectiv= e, perhaps subliminal originally, was to make program
behavior easy to r= eason about. Thus pipes were accepted into research
Unix, but more gener= al (and unruly) IPC mechanisms such as messages
and events never were.
The infrastructure had to be asynchronous. The whole point was to
= surmount that difficult model and keep everyday programming simple.
User= visibility of asynchrony was held to a minimum: fork(), signal(),
wait(= ). Signal() was there first and foremost to support SIGKILL; it
did not = purport to provide a sound basis for asynchronous IPC.
The complexity of= sigaction() is evidence that asynchrony remains
untamed 40 years on.
"""

My response at the = time was to question whether asynchrony itself remains untamed, as Doug put= it, or if rather it has proved difficult to retrofit asynchrony onto a sys= tem designed around fundamentally synchronous primitives?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.

--0000000000000758e705a71e0604--