On Sat, 14 Feb 2004 06:24:59 -0800, Amit wrote:
You'll have to be more specific than "unpredictable results".
Unless you've explicitly put the file descriptors into non-blocking mode
then, yes, a read from a pipe will block until there is data available.
However, note that pipes behave like network sockets, not files. Let's
consider the following timeline where process A is writing data into the
pipe and process B is reading the data:
process A process B
The read() from process B will read the four bytes in the pipe and have a
return value of four. It will not block until eight bytes are available. On
a monoprocessor system it will frequently be the case that both write()'s
by process A will complete before process B is allowed to run. So process
B's read() will normally return all eight bytes. But there is no guarantee
that will happen. It's possible for a context switch to occur between the
two write()'s by process A. And on a multiprocessor system it is even more
likely that only part of the data will be in the pipe when process B issues
it's read() since the two processes can be running simultaneously on
Also, don't forget that pipes can buffer only a finite amount of data. If
process A attempts to write more data than the pipe can buffer than part of
the contents of buf will put into the pipe and process A will be put to
sleep until process B reads that data. Process A will then be woken up and
allowed to copy more data from its buf into the pipe.