Taylor R Campbell <[email protected]> writes: >> 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
Many thanks for the fix and detailed report! Sorry, my notes about the bug from a few months ago were not very detailed. I wish explained it in more detail with kdump output, for my understanding a few months down the line as well. Collin
