Re: hot-backup script produces zombie?

At 11:01 AM +0200 8/29/03, mailing.lists@gmx.net wrote:
>
>when i start the python script ps reports an zombie ..
>when i the python script is finished or killed the "zombie" is gone...
>...
>any idea why this happens?

Just guessing, here, but it appears the short-form answer is "Windows."

The longer form goes like this:

The on-line Python dox,
http://www.python.org/doc/current/lib/os-newstreams.html#l2h-1381,
say:
>These methods do not make it possible to retrieve the return code
>from the child processes. The only way to control the input and
>output streams and also retrieve the return codes is to use the
>Popen3 and Popen4 classes from the popen2 module; these are only
>available on Unix .

Now, the reason the OS defines such a thing as a "zombie" is exactly
to hold that "return code". This is highly Unixish. The way you get
that return code (in the C code inside the Python engine, in this
case) is to "wait" for the zombie, which clears ("reaps") the zombie
and gives you the return code. Now, the fact that these routines
don't offer to return the return code surely means they don't collect
it (since, once you have a integer, returning it is trivially easy).
That means, they don't wait(). That means, the zombie doesn't get
reaped. That means, you get a chance to see it in the "ps" output.

Once the script completes, one or the other of two things happens:
the Python interpreter may reap outstanding zombies, or it may simply
die; this causes children (including zombies) to be "orphaned,"
reassigned to be children of the process "init", which always reaps
its zombies (part of its job). Either way, the zombie goes away.

But why doesn't os.popen3() reap the zombie? Evidently, because it's
trying to remain Windows-portable, and you can't get there from here.

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org