[Python-Dev] Request for inclusion in 2.5.2 (5-for-1)

Mike Klaas mike.klaas at gmail.com
Wed Oct 31 22:36:25 CET 2007


Issue http://bugs.python.org/issue1663329 details an annoyance in the  
subprocess module that has affected several users, including me.   
Essentially, closing hundreds of thousands of file descriptors by  
round-tripping through the python exception machinery is very slow,  
taking hundreds of milliseconds and at times many seconds.  The  
proposed fix is to write this loop in c.  The c function is but a  
handful of lines long.  I purposefully kept the implementation  
trivial so that it will work on all unix variants (there is another  
issue that contains a super-duper optimization for AIX, and other  
possibilities exist for Solaris, but the simple fix yields a ten-fold  
speedup everywhere but windows, so I didn't think that it was worth  
the complexity).

Though technically relating only to performance, I consider this a  
bug-fix candidate as mysterious multi-second delays when launching a  
subprocess end up making the functionality of close_fds unusable on  
some platform configurations (namely, those with high MAX_FD set).

It would be great to see this is 2.5.2.  Understanding that issue  
evaluation takes significant effort, I've done some evaluation/triage  
on other open tickets:
----------------------------------------
See issues for detailed comments.

http://bugs.python.org/issue1516330:  No clear problem, invalid  
patch.  Recommend rejection.

http://bugs.python.org/issue1516327:  No clear problem, no patch.  
Recommend closing.

http://bugs.python.org/issue1705170:  reproduced.  Conjecture as to  
why it is occurring, but I don't know the guts well enough to propose  
a decent fix.

http://bugs.python.org/issue1773632: tested patch.  Recommend  
accepting unless there are things I don't know about this mysterious  
_xmlrpclib extension (which there doubtlessly are)

http://bugs.python.org/issue738948: Rather old PEP that has gathered  
no comments.  Calling it a "PEP" is generous--it is really just a  
link to an academic paper with a note about how this might be  
integrated into Stackless.

Thanks,
-Mike


More information about the Python-Dev mailing list