I agree that blocking shutdown by default isn't a good idea. A child will
eventually get indefinitely stuck on a nonresponsive connection and hang
the whole server. This behavior change is surprising and should be reverted
in master, and definitely not backported.
As for block-timeout or block-tim
I just pushed a change to Bedevere to help track what stage a pull request
is in. The stages are:
- awaiting review
- awaiting core review
- awaiting changes
- awaiting change review
- awaiting merge
The "review" stage is for when a pull request has no reviews either
approving or
ACTIVITY SUMMARY (2017-08-04 - 2017-08-11)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6116 (+16)
closed 36820 (+46)
total 42936 (+62)
Open issues wit
Common pattern I've used is to wait a bit, then send a kill signal.
M
--
Matt Billenstein
m...@vazor.com
Sent from my iPhone 6 (this put here so you know I have one)
> On Aug 11, 2017, at 5:44 AM, Victor Stinner wrote:
>
> Hi,
>
> I'm working on reducing the failure rate of Python CIs (Travi
Hi,
I'm working on reducing the failure rate of Python CIs (Travis CI,
AppVeyor, buildbots). For that, I'm trying to reduce test side effects
using "environment altered" warnings. This week, I worked on
support.reap_children() which detects leaked child processes (usually
created with os.fork()).
