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 7dcf41f0
	for <ml@inbox.vuxu.org>;
	Sun, 4 Nov 2018 23:08:52 +0000 (UTC)
Received: by minnie.tuhs.org (Postfix, from userid 112)
	id CA3BDA21F6; Mon,  5 Nov 2018 09:08:51 +1000 (AEST)
Received: from minnie.tuhs.org (localhost [127.0.0.1])
	by minnie.tuhs.org (Postfix) with ESMTP id 4257CA21D9;
	Mon,  5 Nov 2018 09:08:31 +1000 (AEST)
Received: by minnie.tuhs.org (Postfix, from userid 112)
 id B7358A21F7; Mon,  5 Nov 2018 08:37:52 +1000 (AEST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
 by minnie.tuhs.org (Postfix) with ESMTPS id 1DB3FA2209
 for <tuhs@tuhs.org>; Mon,  5 Nov 2018 08:37:47 +1000 (AEST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178)
 id 4B8D018C0B6; Sun,  4 Nov 2018 17:37:46 -0500 (EST)
To: tuhs@tuhs.org
Message-Id: <20181104223746.4B8D018C0B6@mercury.lcs.mit.edu>
Date: Sun,  4 Nov 2018 17:37:46 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
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 <tuhs.minnie.tuhs.org>
List-Unsubscribe: <https://minnie.tuhs.org/cgi-bin/mailman/options/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=unsubscribe>
List-Archive: <http://minnie.tuhs.org/pipermail/tuhs/>
List-Post: <mailto:tuhs@minnie.tuhs.org>
List-Help: <mailto:tuhs-request@minnie.tuhs.org?subject=help>
List-Subscribe: <https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs>,
 <mailto:tuhs-request@minnie.tuhs.org?subject=subscribe>
Cc: jnc@mercury.lcs.mit.edu
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

    > From: Chris Hanson

    > you should virtually never use read(2), only ever something like this:
    > ...
    > And do this for every classic system call, since virtually no client
    > code should ever have to care about EINTR.

"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?

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?)

	Noel

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.