[TUHS] v3 pipes

[Paul Ruizendaal]

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200425/0953f3dd/attachment.html>