Re: PR kern/60944: fifo opened non-blocking and set to blocking regression

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

> Date: Fri, 30 Oct 2026 17:50:08 +0000 (UTC)
> From: Christos Zoulas <christos%zoulas.com@localhost>
> 
> 	Select should block if there are no writers on freshly opened FIFO
> 	that is set to blocking.

[citation needed]

I reviewed all the relevant language in POSIX.1-2024 as research for
PR kern/60792 (fifo: poll reader before writers?).  It clearly
prescribes (and other operating systems agree, and applications like
GNU coreutils have long relied on the assumption) that _reading_ must
not block -- and must immediately report EOF -- in that case:

	When attempting to read from an empty pipe or FIFO:
	
	   If no process has the pipe open for writing, read()
	   shall return 0 to indicate end-of-file.
	
https://pubs.opengroup.org/onlinepubs/9799919799/functions/read.html

(This was the subject of PR kern/60789 (read on fifo without writer
may block), which arose because applications relying on POSIX
semantics were broken on NetBSD due to an accident dating back to
1990 that FreeBSD fixed back in 1997.)

And if read would return immediately without blocking, it is
internally inconsistent for select to block instead of reporting
immediately that read would not block.

Applications can (and do) simply open the fifo for write if they want
select/poll to reliably wait until a write actually materializes.

(If the applications are going to rely on non-POSIX guarantees, they
can even save a file descriptor and open it once with O_RDWR instead
of twice, one with O_RDONLY and the other with O_WRONLY.  I bet this
works on more operating systems than the previous logic did, including
older NetBSD.)