home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / programm / 5752 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.5 KB
  1. Xref: sparky comp.unix.programmer:5752 comp.unix.questions:14860
  2. Newsgroups: comp.unix.programmer,comp.unix.questions
  3. Path: sparky!uunet!psinntp!hyphenw!dwight
  4. From: dwight@hyphen.com (Dwight Ernest)
  5. Subject: Re: Programs that fork() don't redirect output in desired way?
  6. Message-ID: <1992Dec21.163718.5756@hyphen.com>
  7. Organization: Hyphen, Inc., Wilmington, MA 01887 USA / +1 508 988-0880
  8. References: <941@ncrsaud.SaudiArabia.NCR.COM>
  9. Date: Mon, 21 Dec 1992 16:37:18 GMT
  10. Lines: 48
  11.  
  12. kbahey@ncrsaud.SaudiArabia.NCR.COM (Khalid Bahey-elDin) writes:
  13.  
  14. >The following is the same on AT&T UNIX V.3 and V.4.
  15.  
  16. >The scenario is that a program (a background communication interface) is
  17. >invoked, and it fork()s 2 children. The parent monitors both children, and
  18. >one child deals with inbound traffic, the other with outbound traffic.
  19.  
  20. >In this program, we have a lot of printf()s used for debugging and tracing, and
  21. >are only active when we compile with a -DDEBUG compiler flag.
  22.  
  23. >We let the program run in the background, and redirect stdout, and stderr to a
  24. >holding debug file, via the shell command:
  25.  
  26. >prog > debug.out 2>&1 
  27.  
  28. >Because "prog" breaks itself into three running processes, we have three
  29. >different processes redirecting their output to the debug file.
  30.  
  31. >The problem is that the file does not contain things in chronological order.
  32. >What happens is that it will contain output from the parent, then output from
  33. >child1, then output from child2, all interspersed.
  34.  
  35. >I assume this is because of system buffering for printf()s.
  36.  
  37. >Of course I can rewrite the printf()s so as they would write to a special log
  38. >file, but this would be a considerable effort, plus it will deprive us of the
  39. >flexibility of displaying output directly to the terminal when we want to.
  40.  
  41. >What is an easy way to get the output of all three processes correctly in
  42. >correct chronological order?
  43.  
  44. There's no clean way to completely avoid race conditions like you
  45. describe without a coding effort, which you say you're trying to
  46. avoid.
  47.  
  48. A better algorithm, though, if you wanted to recode, would be to have
  49. the parent open the debug file instead of using redirection, and then
  50. use some sort of locking mechanism to allow one instance of the program
  51. to write to the output file at a time.
  52.  
  53. A cheap and easy way to at least mitigate the effect would be to call
  54. fflush() after each printf.  RTFM.  It won't entirely do away with the
  55. problem, but it should help.
  56. -- 
  57. --Dwight A. Ernest   R&D Manager (USA)     I speak only for myself.
  58.   Hyphen, Inc./181 Ballardvale St./Wilmington, MA 01887/+1 508 988 0880 x125
  59.   dwight@hyphen.com
  60.