This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yorick
Recipients
Date 2005-04-21.11:40:17
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
The subprocess module automatically reaps child
processes. It maintains a list of Popen instances, and
each time a new Popen is created, the list is traversed
and a non-polling wait is done for each instance.

I discussed this with the author, Peter Åstrand, and
this behaviour was inherited from the older popen2
code, and is intended to avoid a limitless accretion of
zombies when the user does not take care to wait for
the processes.

However, the auto-reaping interacts badly with
os.wait()/waitpid() since the user is not aware that
the module is reaping children behind her back. In
particular, os.wait(), which is very useful when a
blocking wait for many children is desired, may not
work at all, which caused me to look at the problem in
the first case.

The solution is to allow the user to create Popen
instances that are not auto-reaped. The interface is
otherwise unchanged, and existing code will see no
change in behaviour.

This patch does three things:
- Adds an autoreap parameter to the Popen constructor,
defaulting to True (the previous behaviour)
- Documents the auto-reaper and its interaction with
os.wait()/waitpid(), which was previously missing
- Changes the list of instances to a set, to avoid O(N)
element removal.

For completeness, here is a test case:

import os, subprocess, time
p = subprocess.Popen(["/bin/true"]).pid
time.sleep(1)
subprocess.call(["/bin/false"])
(pid, status) = os.wait()
print "got", pid, "expected", p

The above code will throw an exception. With the patch,
it will work as expected if autoreap=False is added to
the Popen call.
History
Date User Action Args
2007-08-23 15:42:47adminlinkissue1187312 messages
2007-08-23 15:42:47admincreate