home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.18 / text0077.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  3.4 KB
  1. From: bowen@sgi.com (Jerre Bowen)
  2.  
  3. Folks:
  4.  
  5.     I'm wondering if there is an easy way in POSIX to be absolutely 
  6. certain that a process which calls a library routine that forks and waits
  7. on a child does not lose any SIGCLDs.  I apologize for the length of this
  8. article.  Here's the scenario:
  9.  
  10.  
  11. void cldhandler();
  12.  
  13. pid_t pid;
  14.  
  15. main()
  16. {
  17.     sigset_t mtmask;
  18.     struct sigaction action;
  19.  
  20.     sigemptyset(&mtmask);    /* sigsuspend with no sigs blocked */
  21.  
  22.     /* SIGCLD handler runs with SIGCLD blocked */
  23.     sigemptyset(&action.sa_mask);
  24.     sigaddset(&action.sa_mask, SIGCLD);
  25.     action.sa_handler = cldhandler;
  26.     action.sa_flags = 0;
  27.     sigaction(SIGCLD, &action,NULL);
  28.  
  29.     if ( (pid = fork()) == 0) {
  30.         sleep(1);
  31.         exit;
  32.     }
  33.     else {
  34.         forkit();
  35.         sigsuspend(&mtmask);    /* will parent awaken? */
  36.     }
  37. }
  38.     
  39. void
  40. cldhandler(sig)
  41. {
  42.     waitpid(pid, &stat, (WNOHANG|WUNTRACED));
  43. }
  44.  
  45. forkit()
  46. {
  47.     struct sigaction act, oact;
  48.  
  49.     act.sa_handler = SIG_DFL;
  50.     act.sa_mask = 0;
  51.     act.sa_flags = 0;
  52.     sigaction(SIGCLD, &act, &oact);    /* default handling for SIGCLD */
  53.     <process forks and execs a program which runs for at least 1 sec>
  54.     <process does a waitpid() on its child process>
  55.     sigaction(SIGCLD, &oact, NULL);    /* reinstall prior handling */
  56. }
  57.  
  58.  
  59.     The problem here is that the original child of the parent will 
  60. exit while forkit() is executing, and since SIGCLD is SIG_DFL'ed during
  61. that time, a zombie *will* be created, but the SIGCLD will *not* be delivered.
  62. The parent then suspends waiting for the SIGCLD indicating that
  63. its child exited, which of course never arrives.  (Obviously, I am
  64. primarily concerned about the case where forkit() is a library routine, and
  65. the user has no idea what the routine is doing with signals--and
  66. *shouldn't* need to either.)
  67.  
  68.     SysV solves this problem in signal() and sigset() by checking for
  69. zombied children at the bottom of the kernel code, and--if any exist--
  70. re-raising a SIGCLD, thus creating the impression that it is impossible to 
  71. lose a SIGCLD.
  72.  
  73.     BSD requires the user to get around the problem of lost SIGCHLDs
  74. by calling wait3(WNOHANG) until no more children remain to be reaped
  75. whenever one SIGCHLD is received.  But in a BSD version of the above code,
  76. you never get any SIGCHLD, so the parent hangs.
  77.  
  78.     POSIX has provided waitpid in order to allow library routines
  79. such as system(3) and popen/pclose(3), which need to fork and wait for
  80. child processes, to be implemented reliably even in the case that the
  81. calling program has child processes that may terminate while in the
  82. library routines.  But the above program example shows that a conforming
  83. implementation still does not necessarily allow an application program
  84. to depend on facilities like system(3).  The reason is that POSIX explicitly
  85. leaves undefined the question of whether SIGCHLD is raised when a process
  86. with a terminated child for which it has not waited establishes a handler
  87. for SIGCHLD (see section 3.3.1.3 paragraph 3(e)).  One way in which an
  88. implementation can make the above program work properly is to raise
  89. SIGCHLD in this case (i.e. whenever a process with an outstanding zombie
  90. calls sigaction to set a handler for SIGCHLD).
  91.  
  92.     Is there a compelling reason for the standard not to require this
  93. behavior?  Granted the implementor has the ability to make things work
  94. correctly.  But if the behavior isn't required, the writer of conforming
  95. applications can't depend on it.
  96.  
  97.     Is there some other better solution to the problem posed by the sample
  98. program?
  99.  
  100.         Thanks -- Jerre Bowen  (bowen@sgi.com)
  101.  
  102. Volume-Number: Volume 18, Number 79
  103.  
  104.