home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / wizards / 3614 < prev    next >
Encoding:
Text File  |  1992-08-14  |  2.7 KB  |  81 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!krfiny!jeffj
  3. From: jeffj@krfiny.uucp (J. Jonas)
  4. Subject: Re: Queueing of signals
  5. Message-ID: <1992Aug14.173144.20835@krfiny.uucp>
  6. Keywords: SIGCHLD, signals, queueing, sigvec
  7. Organization: Jeff's house of computer pieces
  8. References: <1992Aug13.160824.11077@bwdls61.bnr.ca>
  9. Date: Fri, 14 Aug 1992 17:31:44 GMT
  10. Lines: 69
  11.  
  12. In article <1992Aug13.160824.11077@bwdls61.bnr.ca> gwaters@bwdls139.bnr.ca
  13.     (Glenn Waters) writes:
  14. >I have a program that seems to lose SIGCHLD signals. There are two (or more)
  15. >processes that die simultaneously -- thus generating two SIGCHLDs
  16. >to the parent. I only seem to get the first SIGCHLD.
  17. >
  18. >Are the signals queued? I believe not.
  19.  
  20. The "traditional' Unix signal handler has a variable with
  21. ONE BIT for each signal to indicate that the signal has occurred.
  22. Using signal(2), there's a pointer to a function for each signal
  23. with either ignores it, does a default action, or calls a function that
  24. you specified in the signal(2) call.
  25. Setting the bit causes the corresponding action to take place.
  26. Upon entry to the signal handler, the input bit was reset and
  27. the action could revert to the default.
  28. (That's why signal handlers with signal(2) usually re-catch the
  29. signal as the first action, and then handle re-entrancy).
  30.  
  31. Using sigset(2), there's a "MASK" between the variable of incoming
  32. signals and the signal handler, thus you can hold and release
  33. signal handling.
  34.  
  35. Still, there's only ONE BIT to show that the signal has occurred.
  36. So, yes, you're correct.  Signals are not queued nor counted.
  37. Semaphores or messages are for that.
  38.  
  39. >What is the correct method of catching the subsequent child deaths that are
  40. >not queued?
  41.  
  42. I have a program that spawns 2 processes and then continues to perform
  43. some background processing.
  44. There are times that both children terminate and only one SIGCHILD is
  45. received.  Since any termination causes all to exit, I don't care if
  46. there's an unwaited for child when the process exits.
  47.  
  48. I'm composing this as I post, so play around with this idea:
  49. assume the child signal catcher in being called for possibly
  50. more than 1 child.  Since wait(2) has no NO_DELAY option,
  51. put an alarm around it to time it out when there are no
  52. other terminated children.
  53. If you have a timer that allows sleeps of less than 1 second,
  54. that's even better!
  55.  
  56.  
  57. sigset (SIGCLD, catchSigChild);
  58.  
  59.  
  60. void catchSigChild (int sig)
  61. {
  62. pid_t ret;
  63. int status;
  64.  
  65. alarm (1);
  66. while ((ret = wait (&status)) != (-1))
  67.     {
  68.     alarm (1);  /*  reset alarm  */
  69.     printf("child pid %d terminated with status %d\n", ret, status);
  70.     }
  71. /*  return when wait() returns -1 with ECHILD or EINTR  */
  72. }
  73.  
  74. - Jeffrey Jonas
  75. jeffj@synsys.uucp
  76. -- 
  77. -- 
  78. Jeffrey Jonas
  79.  
  80. jeffj@synsys.uucp
  81.