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 19384 invoked from network); 2 Jun 2020 19:19:06 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2020 19:19:06 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 2DB049CAF1; Wed, 3 Jun 2020 05:19:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 85CD09CA44; Wed, 3 Jun 2020 05:18:46 +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="NnjumWXv"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B63A69CA44; Wed, 3 Jun 2020 05:18:44 +1000 (AEST) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by minnie.tuhs.org (Postfix) with ESMTPS id 3432A9C96B for ; Wed, 3 Jun 2020 05:18:44 +1000 (AEST) Received: by mail-qk1-f176.google.com with SMTP id c12so13649848qkk.13 for ; Tue, 02 Jun 2020 12:18:44 -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=s4T/UKuG9aEbfQfFq50yuLeCyxIBNEbYGwx6m0yJxM4=; b=NnjumWXvgOIvVWZJ7Uz7eqw+RvSz9rJM8P1s+JvuqEcwX2RuvQlgCXZYMBn5B6iJDB 7O6LLKkI+GzRWOLeoKYBSQ/NKDX6+rEqSVNH88LV5tvqLNL2l//TC5uyFSHFsQ1RfhLe MIyTRsanbWilvZtIZ02z+CDQB9r4iUxZTs91o= 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=s4T/UKuG9aEbfQfFq50yuLeCyxIBNEbYGwx6m0yJxM4=; b=Pgsz+RIuwSuGQVRsDzdbyVuyqNoS/Kqe4QLJJ9xsaq89VX9IKeztMCQUdx/UBs0hHx qu0XHjpmGuUVZNE311sUYbh6ytebmglcLR6c1RwyKPKXzprXQ4qOVw7y+1pkGQSoQ2Vt g0WVttqOXu/LJJadjgmIguNFOvxMhgevZYW9HGYroast/3j4U78RgkMWqPE76IhBhvS4 LMY/l7SMBhTQ6S27XOyqS+gV/oPjueuoNYvU5y3Ng2WAP6EW0nPLjgZ/SIvddzXzPVun 7rdkxGcb+IBL1mk8YPPTc9v3AK6IGpOz6oSsfTQI0T/bhOCBTHLPAEov84OEpdjI06sp 0kzw== X-Gm-Message-State: AOAM533qzRGM1CCquZl2mfmMDt05ybR4vDa1QbkHGFu0zT8c6zqj+nhw 889dQ+z6flNjohtEl7m+C2+kGIEQQ9sl+qfRGP7y42/O X-Google-Smtp-Source: ABdhPJzOoWDM26bpfuyyoyz0IjBKIOlATab+Ts3BeJIkMHp3f9DIT8PGySjr9XMdHadVGQ/H77C9Bgb+82H9G8VTe1M= X-Received: by 2002:a37:65cf:: with SMTP id z198mr10807534qkb.133.1591125523175; Tue, 02 Jun 2020 12:18:43 -0700 (PDT) MIME-Version: 1.0 References: <202006021759.052Hx5Et022619@freefriends.org> In-Reply-To: From: Clem Cole Date: Tue, 2 Jun 2020 15:18:16 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="0000000000009a647205a71ec7a9" 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" --0000000000009a647205a71ec7a9 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 2:54 PM Paul Winalski wrote: > I first encountered DOS/360 on a System/360 model 25 with 48K of > memory. This was a one-job-at-a-time batch system, but the I/O > primitive (EXCP--execute channel program) was asynchronous. So I > don't think the small memory rationale really applies. > Hrrmpt... it was single task. Being asynchronous in the I/O and allowed process asynchrony takes a lot more housekeeping. Paul you know I agree with you, it was always an issue with UNIX IMO. The problem is how to do it differently. At Masscomp RRU, our solution was not to try to 'fix it' as much as add a new scheme beside the synchronous one. We added a general AST's mechanism that anyone could use (very much like RSX and VMS in semantics), but left signals alone. We added new async calls, which were just implemented via ioctl's (the universal hack) for the specific HW that supported it. In retrospect, that was an error, it should have been aread(2)/awrite(2) and then added the completion routine/call back as the 4th & 5th parameters. Since Stellix was not Real-Time, we left them out. [ tjt and I have argued about that for years ]. So back to Doug/Dan's answer -- I think for a small system, like the original PDP-7 and the PDP-11/20 putting the effort to make it multiprocess and leaving the I/O synchronous definitely made it easier. Particularly, since what was created with the signal semantics. To me, UNIX got way more right than wrong. I suspect if signals had been more like AST's, the idea of being async might have gone farther. But to use Dennis's like about C being quirky, signals are very quirky. wnj tried to 'fix' them and frankly it just made matters worse. And IMO, signaction(3) as Doug says, is a nightmare. I've generally been a fan of introducing a new idea separately as a 'stronger strain' and then seeing if people likely it. FWIW: A couple of us did try to get AST's into the POSIX.4 (they were there in a draft), but ultimately *.4 was rejected as 'not UNIX.' --0000000000009a647205a71ec7a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 2, 2020 at 2:54 = PM Paul Winalski <paul.winals= ki@gmail.com> wrote:
I first encountered DOS/360 on a System/360 model 25 with 48K o= f
memory.=C2=A0 This was a one-job-at-a-time batch system, but the I/O
primitive (EXCP--execute channel program) was asynchronous.=C2=A0 So I
don't think the small memory rationale really applies.
=
Hrrmpt... it was single task.=C2=A0 =C2=A0Being asynchronous in th= e I/O and allowed process asynchrony takes a lot more housekeepi= ng.=C2=A0 Paul you know I agree with you, it was always an issue with UNIX = IMO.=C2=A0 The problem is how to do it differently.
At Masscomp RRU, our solution was not to try to = 9;fix it' as much as add a new scheme beside the synchronous one.=C2=A0= We added a general AST's mechanism that anyone could use (very much li= ke RSX and VMS in semantics), but left signals alone.=C2=A0 We added new as= ync calls, which were just implemented via ioctl's=C2=A0(the universal = hack) for the specific HW that supported it.=C2=A0 =C2=A0In retrospect, tha= t was an error,=C2=A0it should have been aread(2)/awrite(2) and then added = the=C2=A0completion routine/call back as the 4th & 5th parameters.=C2= =A0 =C2=A0Since Stellix was not Real-Time, we left them out.=C2=A0 [ tjt an= d I have argued about that for years ].

So back to Doug/Dan's answer -- I think for a small system,= like the original PDP-7 and the PDP-11/20 putting the effort to make it mu= ltiprocess and leaving the I/O synchronous definitely made it easier.=C2=A0= =C2=A0Particularly, since what was created with the signal semantics.=C2= =A0 =C2=A0To me, UNIX got way more right than wrong.=C2=A0 =C2=A0I suspect = if signals had been more like AST's, the idea of being async might have= gone farther.=C2=A0 But to use Dennis's like about C being quirky, sig= nals are very quirky.=C2=A0 wnj tried to 'fix' them and frankly it = just made matters worse.=C2=A0 And IMO, signaction(3) as Doug says, is a ni= ghtmare.=C2=A0 =C2=A0=C2=A0

I've gen= erally been a fan of introducing a new idea separately as a 'stronger s= train' and then seeing if people likely it.=C2=A0

= FWIW: A couple of us did try to get=C2=A0AST's into the POSIX.4 (they w= ere there in a draft), but ultimately *.4 was rejected as 'not UNIX.= 9;

--0000000000009a647205a71ec7a9--