Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!clyde!burl!codas!mtune!whuts!picuxa!gp
From: gp@picuxa.UUCP (Greg Pasquariello X1190)
Newsgroups: comp.unix.wizards
Subject: Re: named pipes?
Message-ID: <371@picuxa.UUCP>
Date: Tue, 10-Nov-87 09:35:16 EST
Article-I.D.: picuxa.371
Posted: Tue Nov 10 09:35:16 1987
Date-Received: Sat, 14-Nov-87 18:14:57 EST
References: <15973@topaz.rutgers.edu>
Organization: AT&T Information Systems, Parsippany NJ
Lines: 51
Summary: pipes and FIFOs

In article <15973@topaz.rutgers.edu>, hedrick@topaz.rutgers.edu (Charles Hedrick) writes:
> 
> I keep tripping over code in our kernels that talks about FIFO's and
> named pipes.  Well, we finally had an application where we could use
> such a thing, so I went looking for the documentation.  I am unable to
> find any mentions of FIFO or named pipes anywhere in our System V
> release 2 documentation, or in the Pyramid or Sun man pages, except
> for one place: mknod tells you how to create one.  However it would be
> nice to have something in section 4 that talks about the semantics,
> with a nice title line so that man -k could locate it.  I assume this
> is a System V feature, since it isn't in the 4.3 version of mknod.
> The following simple test works on Sun, Pyramid, and Ultrix, so I can
> sort of guess what it must be doing:
> 
> mknod foo p    
> cat foo >/dev/tty &
> cat .login >foo
> 
> .login comes out the terminal, and the background job finishes at
> the end.  (This shows that EOF on one side is propagated to the
> other.) Anybody know where the documentation is hiding?

EOF is *sortof* propagated from one side to the other.  What is actually
happening is this:

	cat foo > /dev/tty:   	cat is trying to read the pipe foo.  There is
				nothing there, so the read will block (wait)

	cat .login > foo:	.login is catted and written to the pipe.  At
				this point, the pipe is written to, and the
				previous background process now has something
				to read.  The read is satisfied, and prepares
				to do the next blocking read.

	When cat .login finishes, the kernel wakes up any processes that are
	still trying to perform a blocking read on the pipe.  But this is
	*only* because there are no other processes that have opened the pipe
	for writing (it makes no sense to read from a pipe that will never
	be written to).  On the other hand, if other process have opened the
	pipe for writing, the EOF will NOT be propagated to the cat foo.
	Cat foo will still be asleep (performing a blocking read on the pipe).

Some pipe documentation can be gleaned by looking at the open() and read() and
write() system calls in the SysV Programmers Reference.  You might also try 
The Desgin of the Unix Operating System by Bach (it's a little expensive - 
about $50.00).

Sorry, but I don't have any idea where to find any other info on pipes...


Greg