>>> [...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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
