> Date: Fri, 25 Sep 2026 15:09:10 +0100 > From: Pádraig Brady <[email protected]> > > The point wasn't about the first read(), > it was about the blocking in the subsequent read(). > > On Linux for example we see read() always returning 0: > > read(3, "x\n", 8192) = 2 > read(3, "", 8192) = 0 > > read(3, "", 8192) = 0 > clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}) > read(3, "", 8192) = 0 > clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}) > ...
You're right, sorry, I was looking at the wrong read()! I've filed a bug for NetBSD and added a test: PR kern/60789: read on fifo without writer may block https://gnats.NetBSD.org/60789 https://nxr.NetBSD.org/xref/src/tests/lib/libc/sys/t_mkfifo.c?r=1.8#590 In the course of drafting a fix for this (deleting a few lines of code that date back to 1990), I found myself confronted by the difficult question of what to do about poll(), which is not obvious from the text of POSIX, and every OS I tested (NetBSD, FreeBSD, macOS, Linux) is either incompatible with POSIX (read may block instead of returning EOF) or self-inconsistent (poll claims reading would block but reading returns EOF immediately)... If you're curious, I wrote it all up in another bug report here: PR kern/60792: fifo: poll reader before writers? https://gnats.NetBSD.org/60792
