Skip to main content

Browse the archive

Staging
v0.5.1
https://github.com/python/cpython
09 December 2020, 11:06:31 UTC
Revision f4d644f36ffb6cb11b34bfcf533c14cfaebf709a authored by Gregory P. Smith on 30 January 2018, 05:27:39 UTC, committed by GitHub on 30 January 2018, 05:27:39 UTC 
bpo-25942: make subprocess more graceful on ^C (GH-5026)
 
Do not allow receiving a SIGINT to cause the subprocess module to trigger an
immediate SIGKILL of the child process.  SIGINT is normally sent to all child
processes by the OS at the same time already as was the established normal
behavior in 2.7 and 3.2.  This behavior change was introduced during the fix to https://bugs.python.org/issue12494 and is generally surprising to command line
tool users who expect other tools launched in child processes to get their own
SIGINT and do their own cleanup.

In Python 3.3-3.6 subprocess.call and subprocess.run would immediately
SIGKILL the child process upon receiving a SIGINT (which raises a
KeyboardInterrupt).  We now give the child a small amount of time to
exit gracefully before resorting to a SIGKILL.

This is also the case for subprocess.Popen.__exit__ which would
previously block indefinitely waiting for the child to die.  This was
hidden from many users by virtue of subprocess.call and subprocess.run
sending the signal immediately.

Behavior change: subprocess.Popen.__exit__ will not block indefinitely
when the exiting exception is a KeyboardInterrupt.  This is done for
user friendliness as people expect their ^C to actually happen.  This
could cause occasional orphaned Popen objects when not using `call` or
`run` with a child process that hasn't exited.

Refactoring involved: The Popen.wait method deals with the
KeyboardInterrupt second chance, existing platform specific internals
have been renamed to _wait().
Also fixes comment typos.
1 parent 83e64c8
Raw File
Tip revision: f4d644f36ffb6cb11b34bfcf533c14cfaebf709a authored by Gregory P. Smith on 30 January 2018, 05:27:39 UTC
bpo-25942: make subprocess more graceful on ^C (GH-5026)
Tip revision: f4d644f
frozen.c 

/* Dummy frozen modules initializer */

#include "Python.h"
#include "importlib.h"
#include "importlib_external.h"

/* In order to test the support for frozen modules, by default we
   define a single frozen module, __hello__.  Loading it will print
   some famous words... */

/* To regenerate this data after the bytecode or marshal format has changed,
   go to ../Tools/freeze/ and freeze the flag.py file; then copy and paste
   the appropriate bytes from M___main__.c. */

static unsigned char M___hello__[] = {
    227,0,0,0,0,0,0,0,0,0,0,0,0,2,0,0,
    0,64,0,0,0,115,16,0,0,0,100,0,90,0,101,1,
    100,1,131,1,1,0,100,2,83,0,41,3,84,122,12,72,
    101,108,108,111,32,119,111,114,108,100,33,78,41,2,218,11,
    105,110,105,116,105,97,108,105,122,101,100,218,5,112,114,105,
    110,116,169,0,114,3,0,0,0,114,3,0,0,0,250,22,
    46,47,84,111,111,108,115,47,102,114,101,101,122,101,47,102,
    108,97,103,46,112,121,218,8,60,109,111,100,117,108,101,62,
    1,0,0,0,115,2,0,0,0,4,1,
};

#define SIZE (int)sizeof(M___hello__)

static const struct _frozen _PyImport_FrozenModules[] = {
    /* importlib */
    {"_frozen_importlib", _Py_M__importlib, (int)sizeof(_Py_M__importlib)},
    {"_frozen_importlib_external", _Py_M__importlib_external,
        (int)sizeof(_Py_M__importlib_external)},
    /* Test module */
    {"__hello__", M___hello__, SIZE},
    /* Test package (negative size indicates package-ness) */
    {"__phello__", M___hello__, -SIZE},
    {"__phello__.spam", M___hello__, SIZE},
    {0, 0, 0} /* sentinel */
};

/* Embedding apps may change this pointer to point to their favorite
   collection of frozen modules: */

const struct _frozen *PyImport_FrozenModules = _PyImport_FrozenModules;
back to top