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: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.

| I read your idea of signalling process completion back to the calling
| process via a pipe with interest. It fits in with an idea I'm playing with
| for a threaded DNS server, the idea being that a thread signals the main
| process to awake and deal with the results, so the main process can
| blissfully sleep in a select call until needed. As said server is in C not
| Python, it'll probably be very offtopic to report on success or failure of
| that approach, but intuitively I expect it to work as advertised.

Sure, but it's rather different than what I was talking about there.
I don't expect the child process to actually write anything to the pipe
or be aware in any way of its existence.  Its sole purpose is to generate
end of file when the child exits.  Would be reliable only if certain
details are worked out, though.

	Donn Cave, donn at drizzle.com