Re: FIFO blocking behaviour

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> [...does FIFO write block until data is read...]
>> No, or at least, I doubt it because NetBSD's implementation doesn't
>> work that way.
(on 9.1, 5.2, and 1.4T)
> It blocks on 10.

That's not what I see on a 10.1_STABLE machine I have a guest login on;
I see the behaviour I describe (and expect).

Are you sure you're not confusing this with the behaviour (which I *do*
expect) of seeing the FIFO open block until a matching open is done?
(Many ways of doing the read and/or write, especially from a shell,
tend to impose no particular delay from "open for write" to "write", or
"open for read" to "read", which can make them appear to be the same.)

In my test, the "(sleep 10; cat) < p" part doesn't start until the
"echo foo > p" part starts; the shell blocks trying to open p.  You can
see this by waiting more than 10 seconds before doing the echo; I find
the cat delayed ten seconds from the time of the echo, not the time of
issuing the "(sleep 10; cat) < p" command-line.  You can also do
something like "(sleep 5; echo foo) > p" as the writer; varying the
sleep times can help distinguish between "open for write" and "write",
and between "open for read" and "read".  You could also do

(echo "opened for read" 1>&2; sleep 10; cat) < p

and/or

(echo "opened for write" 1>&2; sleep 5; echo foo) > p

or the like.

> It also blocks on Debian trixie.

I haven't found a Debian trixie machine at work to try it on myself,
but I do see the behaviour I described on three work Linux machines,
one of them Ubuntu 22.04 jammy (kernel 5.15.0-86-generic), one devuan
daedalus (kernel 6.1.0-40-amd64), and one Debian bullseye (kernel
5.10.0-33-amd64).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B