René's URL Explorer Experiment

Title: bpo-25942: Added new parameter to subprocess.run(): cleanup_timeout by stuarteberg · Pull Request #4283 · python/cpython · GitHub

Open Graph Title: bpo-25942: Added new parameter to subprocess.run(): cleanup_timeout by stuarteberg · Pull Request #4283 · python/cpython

X Title: bpo-25942: Added new parameter to subprocess.run(): cleanup_timeout by stuarteberg · Pull Request #4283 · python/cpython

Description: EDIT: This PR was ultimately superseded by #5026 Summary: subprocess.call() (and now also subprocess.run()) behave badly in the event of SIGINT, i.e. a user hitting Ctrl+C while the subprocess is running. This was first reported by @pilcrow in [bpo-25942]1. Several possible solutions were discussed (by @vadmium, @pilcrow, and @Haypo), but no action was taken. Among them was this suggestion from @Haypo: If you really want to give time to the child process, I suggest to add a new optional parameter . For example ctrlc_timeout=5.0 IMHO, that is the best option, and certainly much better than the status quo. I've implemented that solution in this PR. (It is also similar to a proposal by @vadmium in that thread.) Background: POSIX behavior for Ctrl+C In general, when the user hits Ctrl+C, the OS sends SIGINT to all processes in the foreground process group, including any child processes launched via subprocess call(). That is, both Python and it's child will automatically see the SIGINT; there is no need to explicitly send a duplicate SIGINT to the child. What this PR does: Upon receiving the SIGINT in the form of a KeyboardInterrupt, call() will wait again for the child process, but with cleanup_timeout, giving the child process time to perform cleanup actions. If that timeout expires, then the child process is killed. (Alternatively, during this time, the user can hit Ctrl+C again to immediately stop waiting and kill the child process.) What this PR does not do: This PR attempts to make subprocess.call() behave in a less surprising manner in the context of interactive terminal applications, in which the user is likely to expect Ctrl+C to work properly. If the child process does not handle SIGINT properly, we make no attempt to kill it via alternative means, such as SIGTERM. If the developer needs such control over how the child is to be killed in the event of a KeyboardInterrupt, she should use the Popen API directly instead of calling subprocess.call() or run(). Open question 1: It is not entirely clear what the default value of cleanup_timeout should be. Setting it to 0 by default seems to defeat the purpose and wouldn't help naïve users write code that "just works". On the other hand, setting it to an arbitrary value like 5.0 seems... arbitrary. If the cleanup takes a long time, then we'd be killing it too soon. But if the child doesn't handle SIGINT anyway, then we'd be wasting 5 seconds for no reason (unless the user hits Ctrl+C a second time). For now, I've set the default value as follows: If timeout was specified, use that. The child cleanup time must be less than its total expected runtime. If timeout was not specified, then use 1.0. If the child process handles SIGINT, this introduces no extra delay. If it does not handle SIGINT, then 1 second seems like a reasonable delay for what is likely a rare event an interactive console application. Open question 2: According to the docs, subprocess.call() is equivalent to subprocess.run().returncode. Yet, these are currently implemented as independent functions (and I left it that way). Is there any objection to replacing subprocess.call() with the following? def call(*popenargs, timeout=None, cleanup_timeout=None, **kwargs): return run(*popenargs, timeout=timeout, cleanup_timeout=cleanup_timeout, **kwargs).returncode (That would also allow me to remove the mostly duplicated test code in this PR.) https://bugs.python.org/issue25942

Open Graph Description: EDIT: This PR was ultimately superseded by #5026 Summary: subprocess.call() (and now also subprocess.run()) behave badly in the event of SIGINT, i.e. a user hitting Ctrl+C while the subprocess is ...

X Description: EDIT: This PR was ultimately superseded by #5026 Summary: subprocess.call() (and now also subprocess.run()) behave badly in the event of SIGINT, i.e. a user hitting Ctrl+C while the subprocess is ...

Opengraph URL: https://github.com/python/cpython/pull/4283

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width