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 Mike Pomraning
Recipients Mike Pomraning, SilentGhost, martin.panter, rpcope1, vstinner
Date 2016-04-13.03:26:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1460518001.88.0.119635374302.issue25942@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, standard UNIX terminal behavior is to map Ctrl-C to a SIGINT sent to the foreground process group, so that every member of a pipeline (e.g.) or hidden helper children processes can be terminated by the interactive user and have the chance to clean up.

Handling a child process behind a convenience interface, like system() or subprocess.call(), is inherently a bit tricky when things go wrong.

My expectation for .call() would be that it behave something like os.system() (or the C library system() for that matter) and _not_ be interrupted by conventional signals.  That the EINTR be "swallowed" and the p.wait() resumed, as _try_wait() does already.  That way a user timeout= does what we want, but a Ctrl-C has familiar semantics.

Yes, it will be possible for a coder to contrive to throw some other exception during the wait() ... in that case we should close the pipes but _not_ kill and reap the child.  There will be zombies.  Zombies are better than SIGKILLing a 3rd-party process that perhaps needs a graceful shutdown.
History
Date User Action Args
2016-04-13 03:26:42Mike Pomraningsetrecipients: + Mike Pomraning, vstinner, SilentGhost, martin.panter, rpcope1
2016-04-13 03:26:41Mike Pomraningsetmessageid: <1460518001.88.0.119635374302.issue25942@psf.upfronthosting.co.za>
2016-04-13 03:26:41Mike Pomraninglinkissue25942 messages
2016-04-13 03:26:41Mike Pomraningcreate