home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / question / 13503 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.2 KB  |  54 lines
  1. Newsgroups: comp.unix.questions
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsi!ft
  3. From: ft@cbnewsi.cb.att.com (frederick.d.true)
  4. Subject: Unlocking named pipes
  5. Organization: AT&T
  6. Date: Tue, 17 Nov 1992 06:11:16 GMT
  7. Message-ID: <1992Nov17.061116.3260@cbnewsi.cb.att.com>
  8. Followup-To: ftrue@attmail.att.com
  9. Keywords: named pipe 
  10. Lines: 42
  11.  
  12. I'm having a bit of trouble figuring out what's wrong with the
  13. following usage of named pipes. I have 12 large compressed files which
  14. I would like to merge/sort (they are sorted) without having to
  15. decompress all of them before merging. So, I've written a simple script
  16. to create 12 named pipes with mknod, say pipe1..pipe12. I begin
  17. background processes to zcat each of the 12 files to one of the pipes
  18. in sequence. I then start 'sort <switches> -m pipe1 .. pipe12 | <stuff> >
  19. outputfile'.
  20.  
  21. Things go fine for a while, then the entire process freezes. The
  22. output stream stops, and all processes go into IW wait, as if waiting
  23. for something to happen. While in deadlock, if I try to read any of
  24. the pipes, they each have data waiting, so all seems to be fine. So
  25. who stopped everything and why?
  26.  
  27. Sort is able to merge at most 16 files at once, so I don't think
  28. there's anything wrong there. Is there another anomoly in sort that
  29. might cause this failure?
  30.  
  31. As best I can tell, sort found a depleted pipe that zcat couldn't keep
  32. up with (perhaps sort is reading large buffers?), but no EOF, and
  33. started sleeping. However, this isn't logical since the sort process
  34. is followed by 3 other heavyweight processes in the pipe before the
  35. output is written, so I would think that zcat could feed the pipes
  36. fast enough. Besides, I thought processes would handle FIFO's normally
  37. and sleep for at most a few seconds if it found and empty one before
  38. hitting EOF.
  39.  
  40. By the way, in case it proves significant: I'm using SunOS 4.1.2 on a
  41. SPARC. Standard sort, zcat, etc. Named pipes are created with mknod
  42. -p. I've also tried sleeping for a few seconds before starting things,
  43. with no results.
  44.  
  45. Can someone clear up the confusion, or at least add postulations to
  46. the heap?
  47.  
  48. Please e-mail to ftrue@attmail.att.com or post here.
  49.  
  50. --
  51. Fred True
  52. AT&T
  53.  
  54.