Re: kern/60792: fifo: poll reader before writers?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Consider the following operations on a named pipe:
> 
> 1. rd0 = open("fifo", O_RDONLY|O_NONBLOCK)
> 2. wr = open("fifo", O_WRONLY); close(wr)
> 3. rd1 = open("fifo", O_RDONLY|O_NONBLOCK)
> 
> If you try to read from rd0 or rd1 after each step, what should
> happen?  If you poll rd0 or rd1 for POLLIN after each step,
> what should you get?
> [...]
> => Linux 6.1.0:
>    1. read EOF                  poll 0          *bzzt*
>    2. read EOF                  poll POLLHUP
>    3. rd0: read EOF             poll POLLHUP
>       rd1: read EOF             poll 0          *bzzt*
> => FreeBSD 13.0:
>    1. read *block*              poll 0
>    2. read EOF                  poll POLLIN|POLLHUP
>    3. rd0: read EOF             poll POLLIN|POLLHUP
>       rd1: read EOF             poll 0          *bzzt*
> [...]
> The lines marked *bzzt* are internally inconsistent: poll fails
> to report that the fd is readable when a read would return an
> immediate result.
> 
> With my naive patch for PR 60789 (to apply a change that
> FreeBSD made back in 1997), I get:
> 
> => NetBSD patched for PR kern/60789:
>    1. read EOF                  poll POLLIN|POLLHUP
>    2. read EOF                  poll POLLIN|POLLHUP
>    3. rd0: read EOF             poll POLLIN|POLLHUP
>       rd1: read EOF             poll POLLIN|POLLHUP
> 
> That's internally consistent _and_ agrees with POSIX for the
> read behaviour.  But what about the poll results?  Is that the
> right thing?

The advantage of the Linux and FreeBSD semantics is that you can open
a fifo for reading without blocking to get a file descriptor, and then
use select/poll to wait for a writer to open.

But it is internally inconsistent (poll returns 0 events ready but you
can read (EOF) without blocking!), and maybe if you want to wait for a
connection, you should just use sockets instead of fifos anyway.

And it requires keeping per-open state rather than per-vnode state,
which would require restructuring our fifo code, which is annoying!