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, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24889 invoked from network); 31 May 2020 11:10:17 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 31 May 2020 11:10:17 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 6CC569CA2E; Sun, 31 May 2020 21:10:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EB7AC9C5E5; Sun, 31 May 2020 21:09:43 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="qpbYvg5S"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B55459C1EA; Sun, 31 May 2020 21:09:39 +1000 (AEST) Received: from cpsmtpb-ews04.kpnxchange.com (cpsmtpb-ews04.kpnxchange.com [213.75.39.7]) by minnie.tuhs.org (Postfix) with ESMTP id 9B7C79C5E5 for ; Sun, 31 May 2020 21:09:33 +1000 (AEST) Received: from cpsps-ews20.kpnxchange.com ([10.94.84.186]) by cpsmtpb-ews04.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Sun, 31 May 2020 13:09:32 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=(e1=10;e3=10;e2=11;e4=10);EVW:Whi te;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.3 cv=O/OiQC1W c=1 sm=1 tr=0 cx=a_idp_e a=aIJzBKXFL4aO3PtWP49Erg==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=IkcTkHD0fZMA:10 a=sTwFKg_x9MkA:10 a=DcNI6HPakC_bOKprXHwA:9 a=QEXdDO2ut3YA:10 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.43]) by cpsps-ews20.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Sun, 31 May 2020 13:09:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=5VU/ebnGCYRuV14AC7cXbbIP983p6HzI1FIGJbPMu8k=; b=qpbYvg5SixaWcTAndMWtG/pyXmKCJBiLHRR+1OHkfnw1JO8i/Ca2+44hptWPOhkmcIIHENmSAHU4J oGLSLNz4J8ARJ2GFahZAODe9W34FCekpn7Arp45Pyvjbg3GpFbrJFzpW5wkT2fqK9FAUHrukEFppjy SeGl+HbOv3hTfs9o= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|FjYehKEcHumlVEYXCYGRGNm7vNS67nNaWa3dpIrn+KliJ9bvWmZiMLEGKNVLw4d HeapLsGnXJirtrqQcB0M6RA== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 33d1ca95-a32f-11ea-93ae-005056ab1411; Sun, 31 May 2020 13:09:32 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sun, 31 May 2020 13:09:31 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3445.104.11) X-OriginalArrivalTime: 31 May 2020 11:09:32.0286 (UTC) FILETIME=[F5F1A1E0:01D6373B] X-RcptDomain: minnie.tuhs.org Subject: [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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This time looking into non-blocking file access. I realise that the term = has wider application, but right now my scope is =E2=80=9Ccommunication = files=E2=80=9D (tty=E2=80=99s, pipes, network connections). As far as I can tell, prior to 1979 non-blocking access did not appear = in the Spider lineage, nor did it appear in the NCP Unix lineage. First = appearance of non-blocking behaviour seems to have been with Chesson=E2=80= =99s multiplexed files where it is marked experimental (an experiment = within an experiment, so to say) in 1979. The first appearance resembling the modern form appears to have been = with SysIII in 1980, where open() gains a O_NDELAY flag and appears to = have had two uses: (i) when used on TTY devices it makes open() return = without waiting for a carrier signal (and subsequent read() / write() = calls on the descriptor return with 0, until the carrier/data is there); = and (ii) on pipes and fifo=E2=80=99s, read() and write() will not block = on an empty/full pipe, but return 0 instead. This behaviour seems to = have continued into SysVR1, I=E2=80=99m not sure when EAGAIN came into = use as a return value for this use case in the SysV lineage. Maybe with = SysVR3 networking? In the Research lineage, the above SysIII approach does not seem to = exist, although the V8 manual page for open() says under BUGS "It should = be possible [...] to optionally call open without the possibility of = hanging waiting for carrier on communication lines.=E2=80=9D In the same = location for V10 it reads "It should be possible to call open without = waiting for carrier on communication lines.=E2=80=9D The July 1981 design proposals for 4.2BSD note that SysIII non-blocking = files are a useful feature and should be included in the new system. In = Jan/Feb 1982 this appears to be coded up, although not all affected = files are under SCCS tracking at that point in time. Non-blocking = behaviour is changed from the SysIII semantics, in that EWOULDBLOCK is = returned instead of 0 when progress is not possible. The non-blocking = behaviour is extended beyond TTY=E2=80=99s and pipes to sockets, with = additional errors (such as EINPROGRESS). At this time EWOULDBLOCK is not = the same error number as EGAIN. It would seem that the differences between the BSD and SysV lineages in = this area persisted until around 2000 or so. Is that a fair summary? - - - I=E2=80=99m not quite sure why the Research lineage did not include = non-blocking behaviour, especially in view of the man page comments. = Maybe it was seen as against the Unix philosophy, with select() offering = sufficient mechanism to avoid blocking (with open() the hard corner = case)? In the SysIII code base, the FNDELAY flag is stored on the file pointer = (i.e. with struct file). This has the effect that the flag is shared = between processes using the same pointer, but can be changed in one = process (using fcntl) without the knowledge of others. It seems more = logical to me to have made it a per-process flag (i.e. with struct user) = instead. In this aspect the SysIII semantics carry through to today=E2=80=99= s Unix/Linux. Was this semantic a deliberate design choice, or simply an = overlooked complication?