Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

[Carl Edquist]

PS:

On Fri, 2 Dec 2022, Carl Edquist wrote:

> On the topic of implementation - I was thinking more about a general 
> solution for filter utils, and I am thinking the key thing is to provide 
> a replacement (wrapper) for read(2), that polls two fds together (one 
> input and one ouput), with no timeout.
>
> It would check for POLLIN on input (in which case do the read()). 
> Otherwise if there is an error (POLLERR or POLLHUP) on input, treat it 
> as EOF. Otherwise if there's an error on output, remove this output, or 
> handle it similar to SIGPIPE/EPIPE.
>
> (Nothing is written to the output fd here, it's just used for polling.)
>
> ...
>
> I think this general approach of using poll(2) for a single input along 
> with a single ouput could be used for both tee and other filters that 
> only write to stdout.


A question for Pádraig (or anyone else who might know) -

Are there portability concerns with the system poll(2), or just with the 
gnulib replacement for poll(), which is based on select(2) ?

The commit message (3a1c328cd) seems to suggest the latter.

In other words, are there any platforms that do not support using the 
system poll(2) directly?

tail.c seems to use poll(2) for _AIX || __sun || __APPLE__ || HAVE_INOTIFY 
and *otherwise* it uses select(2).

But I am thinking, if it's available, poll() is the more appropriate 
interface for this check in the first place.

The 'trick' in tail.c of using select() to test when STDOUT becomes 
available for reading, and taking that as an indication of an error 
condition, doesn't seem to be documented (in my linux select(2)), and also 
seems like it might not work as intended if fd 1 is open for read-write.


Anyway if it's possible just to use poll(2) (the system one, not the 
gnulib replacement), that might simplify the portability logic.


What do you think?


Thanks,
Carl