[issue27167] subprocess reports signal as negative exit status, not documented
New submission from David MacKenzie: If a command run by subprocess.check_call() exits because of a signal, e.g. SIGPIPE, Popen._handle_exitstatus() encodes the signal number as a negative return code. check_call() then raises that as a CalledProcessError, which describes it as "returned non-zero exit status -13". This is misleading and undocumented. CalledProcessError.__str__() should check if self.returncode is negative and if so return a string indicating that it was "signal 13", not "exit status -13". Better yet, it should include the descriptive name of the signal, e.g., SIGPIPE. And, the documentation for the subprocess module should note that a signal is converted into a negative returncode. -- components: Library (Lib) messages: 266758 nosy: dmacnet priority: normal severity: normal status: open title: subprocess reports signal as negative exit status, not documented type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers
David MacKenzie added the comment: This issue seems to overlap with 14119. -- ___ Python tracker <http://bugs.python.org/issue24882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers
David MacKenzie added the comment: If each worker thread ties up other resources in an application, such as handles to server connections, conserving threads could have a significant impact. That's the situation for an application I am involved with. I've written and tested a patch to make this change, using a second Queue for the worker threads to notify the executor in the main thread by sending a None when they finish a WorkItem and are therefore idle and ready for more work. It's a fairly simple patch. It does add a little more overhead to executing a job, inevitably. I can submit the patch if there's interest. Otherwise, perhaps the TODO comment in thread.py should be rewritten to explain why it's not worth doing. -- nosy: +dmacnet ___ Python tracker <http://bugs.python.org/issue24882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
