home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / question / 13543 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.5 KB
  1. Xref: sparky comp.unix.questions:13543 comp.unix.wizards:4762
  2. Newsgroups: comp.unix.questions,comp.unix.wizards
  3. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsi!ft
  4. From: ft@cbnewsi.cb.att.com (frederick.d.true)
  5. Subject: Re: Unlocking named pipes (solved + question)
  6. Organization: AT&T
  7. Date: Wed, 18 Nov 1992 00:06:43 GMT
  8. Message-ID: <1992Nov18.000643.26562@cbnewsi.cb.att.com>
  9. Followup-To: comp.unix.questions
  10. Keywords: named pipe FIFO
  11. Lines: 48
  12.  
  13.  
  14. Well, after receiving very few responses to my problem, I did a little 
  15. poking around in the SunOS kernel config files to try and find an
  16. answer.
  17.  
  18. Basically, my problem was this: I was using several named pipes to
  19. receive the output of several 'zcat file...' commands, and was then
  20. using 'sort <ops> -m pipe1 pipe2...' to merge the named pipes
  21. together. The result was that I could merge several large compressed
  22. sorted files, without having to decompress them to disk.
  23.  
  24. The problem was that after running for a while, the process would
  25. freeze and all processes would go into IW. I thought it was strange
  26. that this would happen all by itself, and indeed it didn't. At the
  27. same time, I was testing this process on several smaller files, using
  28. named pipes (different pipes, of course). 
  29.  
  30. I then noticed in the kernel configuration file, the option "options
  31. FIFOCNT=10' was being set. Sure enough, in the "Sun System and Network
  32. Administration" manual, I stumbled across the following, under "Tuning
  33. IPC System Parameters":
  34.  
  35.     FIFOCNT determines the makimum number of FIFOs that may be in
  36.     use in the system an any given time. Attempts to write more
  37.     than FIFOCNT simultaneous FIFOs will block until some FIFOs
  38.     are closed, releasing system resources. In the current 
  39.     implementation, FIFO buffers are allocated in non-paging
  40.     memory, and can lead to system lockup if indiscriminantly
  41.     allocated. This restriction make be removed in a future
  42.     release.
  43.  
  44. Well, that was the problem. The job would run fine as long as I was
  45. using <= 10 pipes. When I fiddled around while the job was running, I
  46. caused several of the pipes to block, and sort would stop, and all
  47. other processes would eventually stop since none of the pipes would
  48. clear until sort was done.
  49.  
  50. I've rebuilt the kernel with FIFOCNT=16 to help me out temporarily,
  51. but my question is this: is it really true that only this many named
  52. pipes can be used at once *in the entire system*? What if 2 users try
  53. to do this at the same time? Or 2 jobs for that matter?
  54.  
  55. It seems very unfriendly, for such a nice feature.
  56.  
  57. --
  58. Fred True
  59. AT&T
  60.  
  61.