[lug] Named pipe and network tool?

[D. Stimits]

Chris Riddoch wrote:
> 
> rm at mamma.varadinet.de writes:
> 
> > On Tue, Jun 05, 2001 at 09:58:18PM -0600, Chris Riddoch wrote:
> > >
> > > Yeah. Any program that reads and writes files doesn't care what *kind*
> > > of file it is, in most cases, as long as it's a file that can be read
> > > and written to.  (for the most part) Even 'cat' could do it.  It's The
> > > Unix Way(TM).  /dev/hda can be treated like a file, though you might
> > > not *want* to, you *could* use "grep" on /dev/hda.  (Naturally, there
> > > are usually better ways to handle certain tasks.  But it's possible!)
> >
> > Hmm, not neccessarily though. This used to be the case in the early days
> > of *NIX. The whole concept fails as soon as the reading program calls
> > 'stat(2)' to get the size of the "file". Some MUA  do this with the
> > signature file and hence can't use a named pipe. Also, nowadays many
> > programs gobble up the whole file with 'mmap(2)' (esp. those who expect
> > largish data files).  Those applications will call 'stat' as well and
> > will get a file size of 0 bytes ....  YMMV.
> 
> That makes sense. Wouldn't the same problem come up with any non-block
> device, then?  If it's a stream, that could probably cause other
> problems.

Almost anything that deals with variable amount of data has to have some
means of figuring out when it is done reading. The type of storage makes
a difference in what is available to determine failure versus actual end
of data. For example, how do you know the difference between a lost
route and a udp client that just stopped responding, or terminated
normally but did not send notice of its termination? You usually have to
look at a mix of conditions, and different signals usually apply to
different types of storage. One of my big pet peeves with windows was
that I used to have to deal with extremely large quantities of data, and
it reported failure based soley on a timeout that I had no control of
(which happens on networked terabytes of data).

> 
> > I'm far away from my copy of Stevens but if memory serves me right
> > you also need some special care to deal with signals if you use pipes
> > instead of "real" files. If the receiving program terminates and the
> > sending program continues to write to the pipe it'll receive a SIGPIPE.
> > Unless you prepare for this case by installing a signal handler the default
> > action as spec. by POSIX will trigger -- your app will terminate.
> 
> Hmm. I have the first volume, but not the second, of Unix Network
> Programming. I'm thinking it might be a worthwhile investment. Then
> again, two weeks of food is also a worthwhile investment.

Food is highly overrated. After a while you'll get over it. :>

> 
> --
> Chris Riddoch         |  epistemological
> socket at peakpeak.com   |  humility
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug