From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 5a60a8e7 for ; Wed, 31 Oct 2018 18:21:37 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 374E3A2312; Thu, 1 Nov 2018 04:21:36 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 38B9BA216D; Thu, 1 Nov 2018 04:21:01 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9EC30A216F; Thu, 1 Nov 2018 03:22:42 +1000 (AEST) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by minnie.tuhs.org (Postfix) with ESMTPS id BF9C2A216D for ; Thu, 1 Nov 2018 03:22:36 +1000 (AEST) Received: by mail-wr1-f50.google.com with SMTP id y16so17390706wrw.3 for ; Wed, 31 Oct 2018 10:22:36 -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=W0qNgi7BTU4SuNrjwxU4Do0YaXO81X+9LH/b+aT4sBI=; b=X2tCkbQr0vydKdF3gUSrsvIQSsNWK+8V1iStB+jHYHirNZc7MJ+EMPDhrFOnNMVcK5 wa/pWqoJdKvUoEPkngZpu8r/CEIxnm38nz5vVOc6n4ZMINxbagOb+UTkmC1WZpbgVW/w eSKQqHu53uMWZn0JDYzULBEwwDrKxQk6HAwec= 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=W0qNgi7BTU4SuNrjwxU4Do0YaXO81X+9LH/b+aT4sBI=; b=BA4DNNvtJ/Ff1h/jdJG32p+KFzhTmItXQTAvy7DqhrJNJCHpB2xgfZZyX+lFRMuR32 0JFPN97umLxLuSA5XkiYN4r0KLqZmBwxJ1h/nN/gJ6reW2InBMvALZSkieF6QhzSd5bV /2PnS2mi3A9rPSfU0tX9aIYknZFOEHFCom8Vg4cmtG2JsNMoT3Q2dRIibnIkbvIAqMoM goh/KYWqFVts5u20TI9SOi6a5iBYrZDF4QD5mh2jQ+IJM2UPNqiwxOCL41v2NRBndy+f wmfULrzkjpNc4awyqgFJacsZo5wSz2zQxu2/9+4yuSWBCoR+l41Rxekn1TSH86BxUPbU AbXw== X-Gm-Message-State: AGRZ1gLjdMwaUPout1sXtt4jD7ZXDQYjx+U9AA1YLeNSYmnrFb2cqgvK di/CILS8k8kkO4GZa2ePU/OL1Jh9BVqCcd7IvLHhuA== X-Google-Smtp-Source: AJdET5ceUJ1YwCedv8lJ++9JgZnKnBI31RRlAi+3dVdRd1rzZacSiS8eOktIvY4wpl4OhKuQEPyNHcMHdYSJQJ/78Bc= X-Received: by 2002:adf:90af:: with SMTP id i44-v6mr3395858wri.77.1541006555272; Wed, 31 Oct 2018 10:22:35 -0700 (PDT) MIME-Version: 1.0 References: <20181031043810.GA10775@minnie.tuhs.org> In-Reply-To: From: Clem Cole Date: Wed, 31 Oct 2018 13:22:08 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="00000000000052f2bc0579898c75" Subject: Re: [TUHS] Unix APIs: elegant or not? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000052f2bc0579898c75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 31, 2018 at 12:51 PM Paul Winalski wrote: > For me one of the most important software design principles is that the > simple and most common use cases should be the simplest for theuser to > code. It's OK if complicated things are complicated to code, but simple things > should be kept simple. > +1 Amen. > > I've always thought that the UNIX file primitives very elegantly adhere > to this principle. Reading a file in UNIX is a simple open()/read().../c= lose() > sequence. Contrast that with VMS's $QIO or IBM OS access methods, where > the full complexity is not only exposed in the interface, it must be > considered, set up, and controlled by the > user for even the simplest operations. As my friend Tom Texiera once so wisely observered, "*it was not so bad that QIO had over a 1000 options, it was that each of them had to be test for on each I/O.*" I also remember having an argument with Culter about QIO vs UNIX I/O (he was defending QIO at the time as it was 'better' - as being more complete). But I pointed out, that it was interesting that after stream I/O was added to VMS, most DEC customers (and the internal language libraries team) had switched to using stream (UNIX style I/O) for most operations because it was simplier and just as fast. It was one of the few times, I saw Dave stop arguing as he really did not have a response. > Multibuffered, asynchronous, interrupt-driven I/O is more complicated (if > not downright clumsy) in UNIX than in VMS or OS/VS, but that's OK, > IMO--it shifts the > complexity burden to those doing complex things. > Exactly, those programs that need to do it, can when they need to. That said, because of our VMS experience, we added ASTs (which I tink are simplier than UNIX signals) and a QIO like call to RTU because the Real-Time customers coming from VMS needed (wanted) it. Truth is async I/O was really useful for some special cases that we had customers that really need use it. But for the most part the simple UNIX 5 I/O calls were good enough (athough I would still rather AST's). BTW: when we added threads we discovered that a lot of the need/use for async I/O also went away and frankly much of the complexity (clumsiness) of the async I/O code was not longer needed, as the threading to care of it and certain was smaller and simplier. Also, I'll agree it was a tad clumsy, but the old double-dd (ddd) program (you can find it in the UUNET archives), uses two processes that communicate via a pipe to do the same trick with a traditional (6th edition) UNIX I/O system to do some of the same things. Basically the two processes, take turns between reading and writing. Thus the asynchronous is purely left in the kernel. The user code is actually very simple. There is a pipe that passes a token back and forth as to when the next read/write can start. For old UNIX systems lacking async I/O, ddd(8) was only way I knew you get a tape drive such as QIC/4 or 8 mm, much less a 1/2 streamer to keep up. Clem =E1=90=A7 --00000000000052f2bc0579898c75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 31, 2018 at 12:51 PM Paul Winalski &= lt;paul.winalski@gmail.com&g= t; wrote:
For me one of the most important software design principles is that the simple and most common use cases should be the simplest for t= heuser to code.=C2=A0
It's OK if complicated things are complicated to c= ode, but simple things should be kept simple.
+1 Amen.=C2=A0

I've always thought that the UNIX file primitives very elegantly adhere to this principle.=C2=A0 Reading a file in UNIX is a simple= open()/read().../close() sequence.=C2=A0 Contrast that with VMS'= ;s $QIO or IBM OS access methods, where the full complexity is n= ot only exposed in the interface, it must be considered, set up,= and controlled by the
user for even the simplest operations.=C2=A0
As my friend Tom Texier= a once so wisely observered, "it was not so bad that QIO= had over a 1000 options, it was that each of them had to be test for on ea= ch I/O."=C2= =A0
I also remembe= r having an argument with Culter about QIO vs UNIX I/O (he was defending QI= O at the time as it was 'better' - as being more complete).=C2=A0 = =C2=A0But I pointed out, that it was interesting that after stream I/O was = added to VMS, most DEC customers (and the internal language libraries team)= had switched to using stream (UNIX style I/O) for most operations because = it was simplier and just as fast.=C2=A0 =C2=A0It was one of the few times, = I saw Dave stop arguing as he really did not have a response.=C2=A0 =C2=A0<= /font>

=C2=A0
Multibuffered, asynchronous, interrupt-driven I= /O is more complicated (if not downright clumsy) in UNIX than in= VMS or OS/VS, but that's OK, IMO--it shifts the
complexity burden to those doing complex things.
Exactly, those= programs that need to do it, can when they need to.=C2=A0 =C2=A0That said,= because of our VMS experience, we added ASTs (which I tink are simplier th= an UNIX signals) and a QIO like call to RTU because the Real-Time customers= coming from VMS needed (wanted) it.=C2=A0 Truth is async I/O=C2=A0 was rea= lly useful for some special cases=C2= =A0that we had customers that really need use it.=C2=A0 =C2=A0But for t= he most part the simple UNIX 5 I/O calls were good enough (athough I would = still rather AST's).

BTW:=C2=A0 when = we added threads we discovered that a lot of the need/use for async I/O als= o went away and frankly much of the complexity (clumsiness) of the async I/= O code was not longer needed, as the threading to care of it and certain wa= s smaller and simplier.

Also, I'll ag= ree it was a tad clumsy, but the old double-dd (ddd) program (you can find = it in the UUNET archives), uses two processes that communicate via a pipe t= o do the same trick with a traditional (6th edition) UNIX I/O system to do = some of the same things.=C2=A0 Basically the two processes, take turns betw= een reading and writing.=C2=A0 =C2=A0Thus the asynchronous is purely left i= n the kernel.=C2=A0 The user code is actually very simple.=C2=A0 =C2=A0Ther= e is a pipe that passes a token back and forth as to when the next read/wri= te can start.=C2=A0 For old UNIX systems lacking async I/O, ddd(8)=C2=A0 wa= s only way I knew you get a tape drive such as QIC/4 or 8 mm, much less a 1= /2 streamer to keep up.

Clem
= 3D""=E1=90=A7
--00000000000052f2bc0579898c75--