On Friday, August 9, 2002, at 09:14 , Ahmed Moustafa wrote:
> If a Perl program generates ZOMBIE/defunct processes, how does that
> affect the system?
[..]
theoretically each process takes up an index in
the process table, and hence one can reach the moment
where the kernel can not fork another process - at
which point various things will start to get weird -
depending upon how the kernel is built.
So the real problem here is working in an OS where
processes can be harvested by 'init' - hence your
worst case is that you will need to kill off the
child of init who is spawning zombie processes, so
that:
a) it stops doing that
b) init inherits all of the 'children'
and lets them exit
the trick of course is to maintain enough control of
the system so that you can do this. It was a lot harder
in the old days when kernels were smaller, and some of
the algorithm for queuing processes were less smart, so
one actually slowed down the system as the length of PIDS
increased and had to be traversed badly....
so your real answer for how to simply avoid this problem
lies in
perldoc -q zombie
which of course references you to
perldoc perlipc
perldoc perlfunc
so the principle trick is to know when, where and
how you are 'forking children' and to do so responsibly.
[..]
given that your code example
use POSIX ":sys_wait_h";
#...
do {
$kid = waitpid(-1,&WNOHANG);
} until $kid == -1;
comes from
perldoc -f waitpid
and your system has implemented the
waitpid(2) or wait4(2)
calls - then you should feel save that it will work
as advertised.
you could of course adopt the strategy as noted in
perldoc -f fork
of simply going with
$SIG{CHLD} = "IGNORE";
so that YOU abandon all hope for your children...
But my preferred strategy is to not fork stuff
willy nilly to begin with and avoid the problem
with simply sound and solid design followed by
correct implementation....
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
