I used os.waitpid,but I still can't Zombie process?

[Donn Cave]

Quoth "lokie.spods" <lokie.spods at ntlworld.com>:
| "Donn Cave" <donn at drizzle.com> wrote in message
| news:1009167768.180019 at yabetcha.drizzle.com...
|> Quoth "lokie.spods" <lokie.spods at ntlworld.com>:
|>| "Donn Cave" <donn at drizzle.com> wrote in message
|>| news:1008825134.967004 at yabetcha.sttl.drizzle.com...
|> ....
|>|> Hm, I think we're going in circles here - if I remember right, he was
|>|> having problems with EINTR because of SIGCHLDs.  Between that and the
|>|> extra problems Python has with signal handling, I personally think SIGCHLD
|>|> is a total loser for Python programs.
|>
|>| As all child processes will raise SIGCHLD upon exit it seems stupid to
|>| ignore the oppertunity to take advantage of the signal and perform cleanup
|>| as its required, working smarter not harder. Now your point mentions EINTR,
|>| regardless of whether you write code to handle that signal, or leave it
|>| unhandled some routines are going to exit anyway with EINTR. Re-reading the
|>| OP's code snippet, it looks like any IO that could exit with EINTR is in the
|>| child and out of scope of that signal anyway.
|>
|> SIGCHLD will abort your I/O functions with EINTR _only_ if you establish
|> a SIGCHLD handler.  It's a last resort.
|
| Which assumes that the calling process left SIGCHLD in its default state.
| You can't make that assumption, for example I know of one shell that defines
| a handler for SIGCHLD which then gets inherited by any subsequent processes.
| Hence after the Christmas cheer has worn off I'll write a few example
| programs to see if the Python interpreter overrides the sigaction with an
| ignore setting.

Well, that's sad, but the solution is SIG_IGN.

	Donn Cave, donn at drizzle.com