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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60792; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/60792: fifo: poll reader before writers?
Date: Sat, 26 Sep 2026 13:35:00 +0000

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