(4.)
+ /* readable event on STDOUT is equivalent to POLLERR,
+ and implies an error condition on output like broken pipe. */
I know this is what the comment from tail.c says, but is it actually
documented to be true somewhere? And on what platforms? I don't see it
being documented in my select(2) on Linux, anyway. (Though it does seem
to work.) Wondering if this behavior is "standard".
Ah!
Well, it's not documented in my (oldish) select(2), but I do find the
following in a newer version of that manpage:
Correspondence between select() and poll() notifications
Within the Linux kernel source, we find the following definitions which
show the correspondence between the readable, writable, and exceptional
condition notifications of select() and the event notifications pro-
vided by poll(2) (and epoll(7)):
#define POLLIN_SET (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP |
POLLERR)
/* Ready for reading */
#define POLLOUT_SET (POLLWRBAND | POLLWRNORM | POLLOUT | POLLERR)
/* Ready for writing */
#define POLLEX_SET (POLLPRI)
/* Exceptional condition */
So I guess (on Linux at least) that means a "readable event on STDOUT" is
equivalent to (POLLRDNORM | POLLRDBAND | POLLIN | POLLHUP | POLLERR).
So, it'll catch the relevant poll() errors (POLLHUP | POLLERR), but the
inclusion of POLLIN results in the gotcha that it will be a false positive if
stdout is already open for RW (eg a socket) and there is actually data ready.
Also, the POLLEX_SET definition of (POLLPRI) doesn't seem relevant; so I
might suggest removing the 'xfd' arg for the select()-based implementation:
POLLPRI
There is some exceptional condition on the file descriptor.
Possibilities include:
* There is out-of-band data on a TCP socket (see tcp(7)).
* A pseudoterminal master in packet mode has seen a state
change on the slave (see ioctl_tty(2)).
* A cgroup.events file has been modified (see cgroups(7)).
Of course, those definitions live in the Linux kernel source, and on Linux
we'd get to use poll() instead of select().
Don't know if the select() <-> poll() correspondence differs at all on other
platforms .. ?
(But, this does give me a bit more confidence about select() being a (mostly)
viable alternative.)
Carl
0001-tee-define-and-use-HAVE_POLL_PIPE_CLOSE_DETECTION.patch