hedrick@topaz.rutgers.edu (Charles Hedrick) (10/27/87)
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?
domo@riddle.UUCP (Dominic Dunlop) (10/29/87)
In article <15973@topaz.rutgers.edu> hedrick@topaz.rutgers.edu (Charles Hedrick) writes: > 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. The facts are pretty boring and pretty typical of UN*X documentation: the major source of documentation for FIFOs is read(2) and write(2). If you have a SVID, edition 2, volume 1, you will at least find these and other entries referenced against FIFO in the index. FIFOs (named pipes) are definitely poor relations of any other IPC mechanism as far as ``how to'' literature is concerned: most authors say words to the effect of ``FIFOs exist'' and leave it at that. Even AT&T's _System V Programmer's Guide_ (Prentice Hall, 1987), which discusses file locking, messages, semaphores and shared memory at great length, does not mention them at all. But then, it doesn't tell us how to use pipes either. We all know how to use pipes, right? (This book is well worth having in most other respects.) One of the few practical programming examples of I've seen is in _UNIX System Programming_ by Ben Salama and Keith Haviland (Addison Wesley, 1987). [A section I reviewed at the draft stage -- while standing in the aliens line at immigration at Newark airport, I seem to recall...] Does anybody know of any others? AT&T has made something of a big deal of the fact that RFS supports access to FIFOs on remote processors, making them very useful for the simple implementation of remote execution daemons and such -- you can even do it with shell scripts. Of course, distributed applications written this way won't currently port to the BSD universe... But where's this documented? I can't seem to put my hands on the right manual... -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
harrison@utfyzx.UUCP (10/29/87)
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. ... > I am unable to find any mentions of FIFO or named pipes anywhere in our > System V release 2 documentation ... > I assume this is a System V feature ... FIFO's were introduced with System III, and being a *good thing* have survived into System V.n. You're right about it not being in BSD, which is their loss (ahem). You're also right about the lack of documentation although it is used in all sorts of places, including lp(1). Rather than get into all the nitty-gritty, I recommend starting with Marc Rochkind's "Advanced UNIX Programming" (Prentice-Hall), in which these critters are discussed quite well in Chapter VII. Also, if people have access to back issues of Hewlett- Packard's "Communicator" series, Mark Surles has a nice article in the March 1985 edition; he begins by saying almost the same things quoted above. -- David Harrison, Dept. of Physics, Univ. of Toronto {ihnp4,utzoo}!utgpu!utfyzx!harrison
arnold@emory.uucp (Arnold D. Robbins {EUCC}) (11/02/87)
In article <507@riddle.UUCP> domo@riddle.UUCP (Dominic Dunlop) writes: >AT&T has made something of a big deal of the fact that RFS supports access >to FIFOs on remote processors, making them very useful for the simple >implementation of remote execution daemons and such -- you can even do it >with shell scripts. Of course, distributed applications written this way >won't currently port to the BSD universe... AT&T aren't the only ones though. Systems with NFS 3.2 and later also support SVID compatible FIFOs and remote FIFOs. I don't really wish to start (another) round of NFS vs. RFS wars; RFS has two major advantages: 1) remote devices, 2) availablity for free on all the V.3 '386 boxes. NFS is much more widely available on larger Unix machines and can be supported on non-Unix OS's (c.f. TWG's VMS port). I can't help but imagine that some future release of NFS will have remote device support, as well. -- Arnold Robbins ARPA, CSNET: arnold@emory.ARPA BITNET: arnold@emory UUCP: { decvax, gatech, }!emory!arnold DOMAIN: arnold@emory.edu (soon) ``csh: just say NO!''
gp@picuxa.UUCP (Greg Pasquariello X1190) (11/10/87)
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
DBLCU@CUNYVM.CUNY.EDU (11/19/87)
If you need an explanation of named pipes try reading The Design of the
Unix Operating System by M.J. Bach. It talks about such animals.
yuf@mentor.cc.purdue.edu (Kyle Grieser) (04/21/89)
In article <5367@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >In article <704@sdrc.UUCP> scwilk@sdrc.UUCP (Ken_Wilkinson) writes: >> >> I am to impliment IPC's for a product. However, message queues >> "may" not do the job for me. It was mentioned that "named pipes" >> could be a solution. Does anyone have a suggestion for sources >> which would document named pipes? Also sample code fragments would >> be helpful too. > >Most of the docs I can find on named pipes are in mknod(2). Yes, from my experience with named pipes there isn't much out there to help you out. mknod(2) is the only place that I could find any information. The best way to learn them is to play with them. As long as you remember that they are FIFOs it is quite easy to see how they behave. Readers will block if there is nothing to read, and writers will block if there is no one reading from the other end. ----- Kyle Grieser, Purdue University Computing Center mentor.cc.purdue.edu!yuf, yuf@mentor.cc.purdue.edu
tel@cbnewsh.ATT.COM (thomas.e.lowe) (04/21/89)
In article <2491@mentor.cc.purdue.edu> yuf@mentor.cc.purdue.edu (Kyle Grieser) writes: >In article <5367@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >>In article <704@sdrc.UUCP> scwilk@sdrc.UUCP (Ken_Wilkinson) writes: >>> >>> I am to impliment IPC's for a product. However, message queues >>> "may" not do the job for me. It was mentioned that "named pipes" >>> could be a solution. Does anyone have a suggestion for sources >>> which would document named pipes? Also sample code fragments would >>> be helpful too. >> >>Most of the docs I can find on named pipes are in mknod(2). > >Readers will block if there is nothing to read, and >writers will block if there is no one reading from the other end. > Actually, it depends upon how one opens the named pipe. With O_NDELAY set, readers and writers will NOT necessarily block. The best source for information about named pipes I found was in the man pages under the open, read, write, and mknod system calls. They all refer to named pipes as 'FIFOS' and talk about the behavior of the particular system call when used on the FIFOS, depending upon wether or not O_NDELAY is set, as well as other things. You will use mknod to create the named pipe if it doesn't already exist. The mknod command wouln't allow you to make pipes. Good luck! -- Tom Lowe tel@hound.ATT.COM or att!hound!tel 201-949-0428 AT&T Bell Laboratories, Room 2E-637A Crawfords Corner Road, Holmdel, NJ 07733 (R) UNIX is a registered trademark of AT&T (keep them lawyers happy!!)
jb@aablue.UUCP (John B Scalia) (04/22/89)
In article <5367@cs.Buffalo.EDU> ugkamins@sunybcs.UUCP (John Kaminski) writes: >In article <704@sdrc.UUCP> scwilk@sdrc.UUCP (Ken_Wilkinson) writes: >> >> I am to impliment IPC's for a product. However, message queues >> "may" not do the job for me. It was mentioned that "named pipes" >> could be a solution. Does anyone have a suggestion for sources >> which would document named pipes? Also sample code fragments would >> be helpful too. > >Most of the docs I can find on named pipes are in mknod(2). You might want to pick up _Advanced_Unix_Programming_ by Marc J. Rochkind. It includes two sections of specific interest: 1) Basic Interprocess Communication 2) Advanced Interprocess Communication and covers pipes, named pipes, semaphores, and shared memory. It is rather specific towards Sys V and Xenix, but portability is discussed. -- A A Blueprint Co., Inc. - Akron, Ohio +1 216 794-8803 voice UUCP: {uunet!}aablue!jb Marriage is a wonderful institution, but who FidoNet: 1:157/697 wants to spend their life in an institution. EchoNet: US:OH/AKR.0