Is Unix stdio slow?

[Chris Torek]

In article <104 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>...  I've long since lost count of how many times
>I've wasted time trying to solve the problem that program A has written
>to a pipe (or socket), program B has done a read on the pipe, and both
>are sitting there getting no cpu time.  True, there are always ways to
>get it to work right.  But the ways are different on every release of
>Unix, and so far, when I ask how to do it right and portably, all I get
>are insults from supposed experts (who I suspect are just trying to cover
>up the fact that they don't know the answer, either).

Use fflush() in the writing program (since you are using stdio [see
Subject]).  If you do not have control over the writing program, you
are out of luck.  Many standard programs never bother to call fflush
since they know that the output is obviously line buffered since it
is *of course* going to a terminal.

Be aware that if you use buffered input in the reading program, it
may make a second call to read() on the pipe or socket descriptor
after first consuming all the available data, and then go back to sleep
waiting for more data.  You can disable this portably and incredibly
inefficiently by setting the input FILE to unbuffered.

[Happy? :-) ]

>BTW, on every Unix system I've ever used, a pipe is a file. ... Is there a
>new implementation of pipes that doesn't use file descriptors?  I sure
>hope not; that sure would be a giant step backwards.

In 4.2BSD and 4.3BSD, and systems based upon them, pipes are sockets rather
than files, but sockets are named by file descriptors just like files.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris