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.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 671ca5cf for ; Mon, 5 Nov 2018 05:04:59 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id BD39AA2306; Mon, 5 Nov 2018 15:04:58 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E187DA21EC; Mon, 5 Nov 2018 15:04:39 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5558AA2161; Mon, 5 Nov 2018 14:04:56 +1000 (AEST) Received: from viclamta30p.bpe.bigpond.com (viclamta30p.bpe.bigpond.com [203.38.21.94]) by minnie.tuhs.org (Postfix) with ESMTPS id 5FF36A2154 for ; Mon, 5 Nov 2018 14:04:55 +1000 (AEST) Received: from smtp.telstra.com ([10.10.26.4]) by viclafep30p-svc.bpe.nexus.telstra.com.au with ESMTP id <20181105040452.MYZN4955.viclafep30p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Mon, 5 Nov 2018 15:04:52 +1100 X-RG-Spam: Unknown X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtkedrjeeggdejiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvfftteenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvufgjkfhffgggtgesthdttddttdervdenucfhrhhomhepffgrvhgvucfjohhrshhfrghllhcuoegurghvvgeshhhorhhsfhgrlhhlrdhorhhgqeenucfkphepuddutddrudeguddrudelfedrvdeffeenucfrrghrrghmpehhvghloheprghnvghurhhinhdrhhhorhhsfhgrlhhlrdhorhhgpdhinhgvthepuddutddrudeguddrudelfedrvdeffedpmhgrihhlfhhrohhmpeeouggrvhgvsehhohhrshhfrghllhdrohhrgheqpdhrtghpthhtohepoehtuhhhshesthhuhhhsrdhorhhgqeenucevlhhushhtvghrufhiiigvpedt X-RG-VS-CLASS: clean Received: from aneurin.horsfall.org (110.141.193.233) by smtp.telstra.com (9.0.019.26-1) id 5BB3FBB605E18EEA for tuhs@tuhs.org; Mon, 5 Nov 2018 15:04:52 +1100 Received: from aneurin.horsfall.org (localhost [127.0.0.1]) by aneurin.horsfall.org (8.15.2/8.15.2) with ESMTP id wA544qRI003791 for ; Mon, 5 Nov 2018 15:04:52 +1100 (EST) (envelope-from dave@horsfall.org) Received: from localhost (dave@localhost) by aneurin.horsfall.org (8.15.2/8.15.2/Submit) with ESMTP id wA544qvQ003788 for ; Mon, 5 Nov 2018 15:04:52 +1100 (EST) (envelope-from dave@horsfall.org) X-Authentication-Warning: aneurin.horsfall.org: dave owned process doing -bs Date: Mon, 5 Nov 2018 15:04:52 +1100 (EST) From: Dave Horsfall To: The Eunuchs Hysterical Society In-Reply-To: <20181104223746.4B8D018C0B6@mercury.lcs.mit.edu> Message-ID: References: <20181104223746.4B8D018C0B6@mercury.lcs.mit.edu> User-Agent: Alpine 2.21.9999 (BSF 287 2018-06-16) X-GPG-Public-Key: http://www.horsfall.org/gpgkey.pub X-GPG-Fingerprint: 05B4 FFBC 0218 B438 66E0 587B EF46 7357 EF5E F58B X-Home-Page: http://www.horsfall.org/ X-Witty-Saying: "chmod 666 the_mode_of_the_beast" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Sun, 4 Nov 2018, Noel Chiappa wrote: > "Virtually". Maybe there are places that want to know if their read call > was interrupted; if you don't make this version available to them, how > can they tell? Leaving the user as much choice as possible is the only > way to go, IMO; why force them to do it the way _you_ think is best? I certainly don't want the kernel making that decision for me; I might want to abandon the entire read() if I was signalled. I did write some code that did that, but I've long since forgotten the details. > And it makes the OS simpler; any time you can move functionality out of > the OS, to the user, that's a Good Thing, IMO. There's nothing stopping > people from using the EINTR-hiding wrapper. (Does the Standard I/O > library do this, does anyone know?) Agreed; the kernel should make as few decisions as possible, and I've used variations on that wrapper, depending on the signal etc. > PS: Only system calls that can block can return EINTR; there are quite a > few that don't, not sure what the counts are in modern Unix. Almost invariably serial lines, and I used to do a lot of that code. -- Dave