[lug] Named pipe and network tool?

[Chris Riddoch]

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.

> 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.

--
Chris Riddoch         |  epistemological
socket at peakpeak.com   |  humility