Moonjoo
Note that I am not the maintainer but just another list denizen.
> I am using "Linux verinet.cis.upenn.edu 2.2.12-20smp #1 SMP" (RedHat).
>
> I ran two processes, one of which writes to a fifo file 4000 bytes and the other
> reads 4000 bytes from the fifo file.
> Sometimes, read or write to the fifo file is blocked without reason.
> Then fifo file has size 4000 or what else left to be read.
>
> verinet:/home/mac/perf> d f
> prw-rw-r-- 1 mac mac 4000 Mar 2 21:36 f
>
> Would you explain what is happening here?
I don't think this is enough information to debug your problem.
However, I do not believe this is a bug in fileutils. The mknod
command only calls the mknod system call in the kernel. And from your
directory listing it appears as if the fifo was created correctly
since the 'p' in the mode listing indicates that it is a pipe.
Therefore mknod worked fine. Your problem must lie elsewhere.
With multiple readers and writers on a pipe you always have to be
aware of deadlock possibilities. A directory listing on a pipe will
show the amount of data that is buffered there and not yet read by a
process. POSIX requires that at least 512 bytes be availble. Most
systems allow an 8k buffer size on a named pipe. You system may have
the getconf command installed in which case you can use it to
determine the actual buffer size. 'getconf f PIPE_BUF'
I note in your uname command that your system is running an SMP
kernel. Since your problem relates specifically to multiple processes
which would normally run on different CPUs in an SMP machine there is
a possibility that there is a problem on that particular machine. You
might try to recreate your problem on a single processor machine as a
way to gather more data to debug the problem.
This mailing list is dedicated to bugs in the fileutils package. I
suggest you continue your discussion in one of the newsgroups
dedicated to linux such as comp.os.linux.help or others.
Good Luck!
Bob
