9p: exit when stdout or stderr is closed

[rakoo]

I often use 9p read long/lived/file | short-lived-process in my scripts. When short-lived-process exits, 9p doesn't see it until it tries to write again, which can be in an indeterminate time.

This PR polls stdout and stderr, assumes that a POLLERR means either was closed, and exits. It has been tested on linux only.

To reproduce:

$ 9p read acme/log | sed '/del/q'

sed should stop as soon as an acme window is closed, and that should inform 9p to stop reading the log. Currently it doesn't.

[dancrossnyc]

Ah, I understand what checkout is doing now, as in the other PR. Cute trick of zeroing events to wait for an error.

My first thought was that this is exactly the sort of thing that SIGPIPE is meant to address, but as you rightly point out, that doesn't really work unless something 9p actually writes on the output.

Unfortunately, as this is written in terms of specific behavior of poll on Linux, which is not necessarily portable to everywhere that plan9port runs (I checked and the same trick does not seem to work on either macOS or illumos, for example: those just remain blocked when a pipe connected to stdout is closed), I don't think it can go in in it's present form. On illumos, it's even worse than that, as a 0 .events member of the pollfd struct doesn't cause poll to block: it just returns immediately.

[rakoo]

Re: [9fans/plan9port] 9p: exit when stdout or stderr is closed (PR #708) – dancrossnyc left a comment (9fans/plan9port#708) Ah, I understand what `checkout` is doing now, as in the other PR. Cute trick of zeroing `events` to wait for an error. My first thought was that this is exactly the sort of thing that `SIGPIPE` is meant to address, but as you rightly point out, that doesn't really work unless something `9p` actually writes on the output. Unfortunately, as this is written in terms of specific behavior of `poll` on Linux, which is not necessarily portable to everywhere that plan9port runs (I checked and the same trick does not seem to work on either macOS or illumos, for example: those just remain blocked when a pipe connected to stdout is closed), I don't think it can go in in it's present form. On illumos, it's even worse than that, as a 0 `.events` member of the `pollfd` struct doesn't cause `poll` to block: it just returns immediately.

Yeah, unfortunately I only have a linux machine handy so I don't even know where to begin to make this portable. This is a larger issue that should be solved at the pipes level really, when downstream is closed upstream should get the signal and close but AFAIK there's no portable way to do that...