There's race condition number one. When is the reader finished? I will not
stop reading until it sees an EOF, which won't happen until it issues a
read() during the brief interval between the iterations of your "echo"
command. So depending on the whim of the scheduler, the reader might see a
single echo, or 2, or 40.
You can sort of get around that by rm'ing and recreating the FIFO in each
iteration, but then you have race condition number two, where the reader will
see either 0 or 1 responses, depending on whether the FIFO exists at the time
the open is attempted.
You can also try putting a "sleep 2" at the end of the loop, to make sure the
reader will have a chance to see the EOF before the next writer jumps in, and
this actually works pretty well, but it is ugly enough to make me wish for
better support from the kernel for this type of thing. (What we really need
is something the behaves for readers like a FIFO, but for writers like an
AF_UNIX socket)
Besides which, the latest versions of finger (both the Linux netkit and the
standard {Net,Free}BSD issue) have explicitly disabled non-regularfile
.plans.
It was a neat hack, and I will miss it, but it never really did work entirely
right.
-- Alan Curry- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/