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 gregory.p.smith
Recipients Mike Pomraning, SilentGhost, gregory.p.smith, martin.panter, rpcope1, vstinner
Date 2017-12-28.04:08:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1514434083.36.0.213398074469.issue25942@psf.upfronthosting.co.za>
In-reply-to
Content
you'll notice I added an alternate PR.  I don't like the complication of adding yet another knob (cleanup_timeout) to subprocesses already giant API surface.  It will rarely be used.

My PR tries to take a practical approach: Just wait a little while (arbitrary value of little chosen in the code) for the child after receiving SIGINT before reraising the exception and triggering a .kill() matching existing behavior.

The one controversial thing in my PR (which could be undone, it is independent of the other changes) is that I also modify the context manager __exit__ behavior to not do an infinite wait() upon KeyboardInterrupt.  This means context managers of Popen _will_ complete potentially leaving a dangling process around (which our existing __del__ will pick up and put in the internal subprocess._active list).  Relatively harmless, but a change none-the-less.

I went that far to try and better match the Python 2.7 and 3.2 behavior: On SIGINT our process sees the KeyboardInterrupt "right away" (not quite as instantaneously here given the wait timeouts, but close enough for interactive command line tool ^C happiness).

It seems like an improvement all around and is IMNSHO less complicated.
History
Date User Action Args
2017-12-28 04:08:03gregory.p.smithsetrecipients: + gregory.p.smith, vstinner, SilentGhost, martin.panter, Mike Pomraning, rpcope1
2017-12-28 04:08:03gregory.p.smithsetmessageid: <1514434083.36.0.213398074469.issue25942@psf.upfronthosting.co.za>
2017-12-28 04:08:03gregory.p.smithlinkissue25942 messages
2017-12-28 04:08:01gregory.p.smithcreate