[TUHS] v3 pipes

[TUHS] v3 pipes

[Paul Ruizendaal]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

>> 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’m not sure I understand.

In the implementation, the read pointer is file location offset (“fp->f_offset”) and the write pointer is the file size (“ip->i_size”). 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 “V6.5” 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?





[-- Attachment #2: Type: text/html, Size: 1818 bytes --]

Re: [TUHS] v3 pipes

[Paul Winalski]

On 4/25/20, Paul Ruizendaal <pnr@planet.nl> wrote:
>
> I just tried making both pipe ends readable+writeable in my “V6.5” 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.

If both pipe ends are readable+writeable, you have the Unix equivalent
of VMS mailboxes.  There's lots of opportunity for both deadlock and
livelock, and some "broken pipe" situations become difficult or
impossible to detect.

-Paul W.

Re: [TUHS] v3 pipes

[Doug McIlroy]

>  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


Doug

[TUHS] V3 pipes

[Paul Ruizendaal]

Was looking into pipes.

For the 3rd Edition TUHS does not have source, but is does have a man page. In V3, pipe returns a single file descriptor that echoes whatever is written back upon reading. The pipe buffer capacity is 504 bytes.

The surviving ‘nsys’ source for V4 does not yet include the source for pipes, but the man page for 4th edition pipes has - more or less - the well known semantics, including the 4096 byte buffer capacity.

Does anyone remember:

- why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. Maybe the reason was that it becomes harder to detect broken pipes?

- whether the V3 implementation was based on an in-memory approach and not the later 'anonymous backing file’? The 504 byte buffer capacity suggests a single buffer page minus some header info.