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 martin.panter
Recipients Mike Pomraning, SilentGhost, martin.panter, rpcope1, vstinner
Date 2016-04-04.21:03:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1459803803.36.0.564276369277.issue25942@psf.upfronthosting.co.za>
In-reply-to
Content
Even if we can’t agree on any behaviour change, I think it might be worth documenting how these functions behave on exceptions (interrupts) other than TimeoutExpired. Currently all I can find is “If the timeout expires, the child process will be killed and waited for.” I think this could be expanded to also say what happens if the parent is interrupted by a signal such as KeyboardInterrupt:

* Current behaviour: Immediately kill child (i.e. timeout expiry is not special)

* Previous behaviour: Return without waiting for child, which will become a zombie

* Mike’s proposal: Wait indefinitely for child without killing it, which could defeat the purpose of the timeout, especially if the child ignores or does not receive the same signal as the parent
History
Date User Action Args
2016-04-04 21:03:23martin.pantersetrecipients: + martin.panter, vstinner, SilentGhost, Mike Pomraning, rpcope1
2016-04-04 21:03:23martin.pantersetmessageid: <1459803803.36.0.564276369277.issue25942@psf.upfronthosting.co.za>
2016-04-04 21:03:23martin.panterlinkissue25942 messages
2016-04-04 21:03:22martin.pantercreate