[issue25942] subprocess.call SIGKILLs too liberally

2016-04-19 Thread Mike Pomraning
Mike Pomraning added the comment: Re: #2, I'd rather have a zombie than a hard kill on a child whose code I perhaps don't control. Zombies are a fact of life (er, a fact of undeath?) in UNIX process management, and are the historical and IMHO expecte

[issue25942] subprocess.call SIGKILLs too liberally

2016-04-14 Thread Mike Pomraning
Mike Pomraning added the comment: #2 and #4 are the only predictable and palatable options, I think. Ignore the patch that started this issue. -- ___ Python tracker <http://bugs.python.org/issue25

[issue25942] subprocess.call SIGKILLs too liberally

2016-04-12 Thread Mike Pomraning
Mike Pomraning added the comment: 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

[issue25942] subprocess.call SIGKILLs too liberally

2015-12-28 Thread Mike Pomraning
Mike Pomraning added the comment: If I understand correctly, the _try_wait mechanics (or 3.5's syscall behavior) already handle EINTR the way we way: ignore it and try wait()ing again. So, this patch would kill only on a timeout, and never on another error like Ctrl

[issue25942] subprocess.call SIGKILLs too liberally

2015-12-24 Thread Mike Pomraning
New submission from Mike Pomraning: Python 3.3 introduces timeout support in subprocess.call, implemented by sending a SIGKILL if the Popen.wait is interrupted by a TimeoutExpired exception. However, the "except" clause is too broad, and will, for instance, trigger on a Keyboar