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

[lokie.spods]

"Donn Cave" <donn at drizzle.com> wrote in message
news:1008825134.967004 at yabetcha.sttl.drizzle.com...
> Quoth "lokie.spods" <lokie.spods at ntlworld.com>:
> ...
> | However you can save a lot of overhead from the loop, by creating a
handler
> | for SIGCHLD and calling waitpid(-1, os.WNOHANG) from within the handler.
See
> | Pythons signal module for more details of that option.
>
> 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.
>
> Once when we were wrestling with this one someone, maybe me, suggested
> a pipe as a signalling device, just leave one end in the child process
> and it will become readable on exit because of the end of file.  Could
> be tricky to get it to work reliably, and of course not great for massive
> numbers of processes, but I don't know if anyone has really checked it
out.
>
> Donn Cave, donn at drizzle.com

OP's code snippet imply's that the original intent of the code is to
continously loop and fork processes, performing cleanup when possible. Now
my first suggestion of calling waitpid in that loop and looping until
waitpid reports no more child processes ready to exit is a good strategy,
however it does add overhead to the main loop.

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.

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.

--
Anthony McDonald

Spammer's please note that spamming this email address with your unsolicited
crap will result in me spamming your network administrators with complaints!