Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bloom-beacon!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.unix.questions Subject: Re: Need help spawning a child Keywords: Signals, Zombies Message-ID: <12244@bloom-beacon.MIT.EDU> Date: 27 Jun 89 03:58:04 GMT References: <1661@apt.UUCP> <873@cbnewsl.ATT.COM> <12131@bloom-beacon.MIT.EDU> <14972@pasteur.Berkeley.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: jik@athena.mit.edu (Jonathan I. Kamens) Distribution: usa Organization: Massachusetts Institute of Technology Lines: 31 In article <14972@pasteur.Berkeley.EDU> gar@cory.Berkeley.EDU.UUCP (Gary D. Wong) writes: >My problem is, that to prevent a zombie process, I have to ignore >SIGCLD with sigignore(SIGCLD), and my parent process does not wake >up. Is there any other way to prevent a zombie other than by >ignoring SIGCLD? I've posted this already; you should read the whole message chain before asking a question that has already been answered. Using sigignore(SIGCLD) to get rid of zombie processes is unportable, and will only work on SysV-based systems. The portable way to get rid of zombie processes is to establish a signal handler for the SIGCLD signal, and to do wait(0) in that signal handler. The wait(0) call cleans up exited child processes and "allows" them to exit. >Also, does anyone know what will happen to my sleeping process after >the signal handling call? Will it go back to sleep, or continue as if >it were given the alarm signal? What would be the effect of having >the signal handler send the alarm signal to the process? If a call to sleep() is interrupted by a signal for which a signal handler has been established, then the sleep() will resume where it left off after the signal handler exits. I am fairly sure this will happen on all architectures; I just tested it on BSD, so I know it will happen there. Jonathan Kamens USnail: MIT Project Athena 432 S. Rose Blvd. jik@Athena.MIT.EDU Akron, OH 44320 Office: 617-253-4261 Home: 216-869-6432