[docs] Python documentation bug

David Barts dbarts at pagedna.com
Fri Jun 17 16:49:10 EDT 2016

This is definitely a documentation bug and it may point to a need for a 
new feature for subprocess.Popen objects as well.

Both the 2.x and 3.x library documentation online claims, in the section 
on the subprocess module:

> P_NOWAIT example:
> pid = os.spawnlp(os.P_NOWAIT, "/bin/mycmd", "mycmd", "myarg")
> ==>
> pid = Popen(["/bin/mycmd", "myarg"]).pid
This is not the case. The reason is that subprocess.Popen objects 
contain a __del__ method which causes exited processes to be 
gratuitously reaped at GC time. The recommended replacement code will 
immediately create an unrefed Popen object, setting in motion a race 
condition: which will run first after the process exits, Python's GC or 
the user code that calls os.wait()?

The __del__ method which does such reaping (arguably the correct 
behavior for the cases where the Popen objects are saved and used to 
subsequently manage the subprocess, something not the case in the above 
example) is still present in both the 2.7.12rc1 and 3.6.0a2 versions of 
the Python library.

To allow the subprocess module to be a true drop-in replacement for the 
os.spawn family, maybe a new feature (call it "noreap" or something 
similar) should to be added to the Popen constructor?

This one just bit me. Thankfully, I had been worried about the 
replacement code (which had occurred to me independently of the manual) 
working properly until I saw it in the Python manual and decided to use 
it given that endorsement, so the cause was fresh in my mind when my 
program started mysteriously "losing" its children.

David Barts
PageDNA, Inc.
Seattle, WA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160617/c4c6e11f/attachment.html>

More information about the docs mailing list