From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 22574 invoked from network); 25 Apr 2020 11:14:58 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 11:14:58 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A98D09C861; Sat, 25 Apr 2020 21:14:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id A473F9C733; Sat, 25 Apr 2020 21:14:25 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="t6sGt5Zj"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B2C7B9C733; Sat, 25 Apr 2020 21:14:21 +1000 (AEST) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by minnie.tuhs.org (Postfix) with ESMTP id C1B189C171 for ; Sat, 25 Apr 2020 21:14:19 +1000 (AEST) Received: from cpsps-ews18.kpnxchange.com ([10.94.84.184]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Sat, 25 Apr 2020 13:14:16 +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=eZemg4MH c=1 sm=1 tr=0 cx=a_idp_e a=YnLMpE5S06+Zisl5ga1zfg==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=cl8xLZFz6L8A:10 a=C6-Zd5ql50QiRrOCNLMA:9 a=QEXdDO2ut3YA:10 a=ndShh_0BlZQFFxyD:21 a=_W_S_7VecoQA:10 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.46]) by cpsps-ews18.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Sat, 25 Apr 2020 13:14:15 +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=X0ZWgsrjvYm1+Wjo/SyJ6HDAYF/Oj8u9qeyK1eEizdM=; b=t6sGt5Zjls6zSl5Lb79WvB5ZNFb52UnhLSfyFjLOZZFEp4Kcpx8tfnR7fcZtfr3S7IXgVDFOcda4W m9t77R4ZetXUIYiHeTc5q7Ncp8yJLuy7wgauSos3pzQio14DO8EdlPLl4/REk144fAEkI1PC7D1GQA 19kzmPPowEfk7faU= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|rAeUSN4EjFyiF+1xBzV4aqEBSKZcNVk7roZSrdkYysjzf4Wa3jH0xjFV5w+0Btz kueX3Hn70sOw4i8l6U1GOqA== X-Originating-IP: 80.101.112.122 Received: from mba1.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id e64f76d9-86e5-11ea-bd55-005056ab7584; Sat, 25 Apr 2020 13:14:16 +0200 (CEST) From: Paul Ruizendaal Content-Type: multipart/alternative; boundary="Apple-Mail=_CD8BC2CA-25ED-492B-86A6-61898D3958F4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <430B2F35-D250-499E-83F9-58D4C1764CE0@planet.nl> Date: Sat, 25 Apr 2020 13:14:15 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3445.9.1) X-OriginalArrivalTime: 25 Apr 2020 11:14:15.0864 (UTC) FILETIME=[A8193380:01D61AF2] X-RcptDomain: minnie.tuhs.org Subject: [TUHS] v3 pipes 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" --Apple-Mail=_CD8BC2CA-25ED-492B-86A6-61898D3958F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> why the single fd approach was abandoned? To its credit, it appears = to allow for limited 2-way communication. > My understanding is that the single file descriptor broke the = open-file > model, which had a single read/write pointer. Two-way communication = via I=E2=80=99m not sure I understand. In the implementation, the read pointer is file location offset = (=E2=80=9Cfp->f_offset=E2=80=9D) and the write pointer is the file size = (=E2=80=9Cip->i_size=E2=80=9D). The location offset on the writing end = of the pipe is always zero, and on the reading end it moves between zero = and PIPSIZ (but that is unobservable). I just tried making both pipe ends readable+writeable in my =E2=80=9CV6.5=E2= =80=9D kernel and that appears to work. It allows for bi-directional = communication in a half-duplex sense (i.e communicating walky-talky = style). The other benefit is using just one file descriptor, at a time = when a process had just 15 to work with. Maybe the issue was that two sides writing to a full pipe at the same = time will cause deadlock? --Apple-Mail=_CD8BC2CA-25ED-492B-86A6-61898D3958F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
why the single fd approach was abandoned? To its credit, it =
appears to allow for limited 2-way =
communication.
My understanding is that the single file descriptor broke the =
open-file
model, which had a single read/write pointer. Two-way communication =
via

I=E2=80=99m not sure I understand.

In the implementation, the read pointer =
is file location offset (=E2=80=9Cfp->f_offset=E2=80=9D) and the =
write pointer is the file size (=E2=80=9Cip->i_size=E2=80=9D). The =
location offset on the writing end of the pipe is always zero, and on =
the reading end it moves between zero and PIPSIZ (but that is =
unobservable).

I=
 just tried making both pipe ends readable+writeable in my =E2=80=9CV6.5=E2=
=80=9D kernel and that appears to work. It allows for bi-directional =
communication in a half-duplex sense (i.e communicating walky-talky =
style). The other benefit is using just one file descriptor, at a time =
when a process had just 15 to work with.

Maybe the issue was that two sides =
writing to a full pipe at the same time will cause deadlock?
= --Apple-Mail=_CD8BC2CA-25ED-492B-86A6-61898D3958F4--