Allow passing creationflags to `multiprocessing` Process implementations to be used to set process creation flags on Windows

[danegsta]

Feature or enhancement

Proposal:

On Windows, there are various process creation flags that control the behavior of spawned processes that can control important behavior such as whether they can receive interrupt signals (and who can send them interrupt signals). A common flag to pass to child process on Windows is CREATE_NEW_PROCESS_GROUP as that allows the child process to receive signals (Ctrl+Break) from the parent process without requiring those signals to be sent to all processes in the console group. Without CREATE_NEW_PROCESS_GROUP, the only way to send an interrupt to a child process on Windows is to send Ctrl+C to all processes in the current console group (creating a new console group is another creationflags option) which would potentially include the current process and one or more parents that may not gracefully handle the interrupt.

The low level subprocess.Popen API includes an optional creationflags argument that is passed to the internal _winapi.CreateProcess call that spawns the actual child process (a ValueError is raised if creationflags is set on a posix OS). I'd like to propose implementing the same behavior in multiprocessing.process.BaseProcess (or in the win32 implementation of multiprocessing.context.SpawnProcess). Accept an optional creationflags member that can be set with a Windows creation flag when running on win32 and apply that value in the call to _winapi.CreateProcess in multiprocessing.popen_spawn_win32.Popen.

This would be a relatively minor API change, but would give much greater control over sub-process behavior on Windows when using the multiprocessing APIs, including better ability to signal spawned processes.

class BaseProcess(object):
    '''
    Process objects represent activity that is run in a separate process

    The class is analogous to `threading.Thread`
    '''
    def _Popen(self):
        raise NotImplementedError

    def __init__(self, group=None, target=None, name=None, args=(), kwargs=None,
                 *, daemon=None, creationflags=0):
        # omitting existing code
        self.creationflags = creationflags

    @property
    def creationflags(self):
        return self._creationflags

    @creationflags.setter
    def creationflags(self, creationflags):
        # Match the behavior of subprocess.Popen creationflags
        assert isinstance(creationflags, int), 'creationflags must be an integer'
        assert creationflags == 0 or sys.platform == 'win32', "creationflags is only supported on Windows platforms"
        self._creationflags = creationflags

class Popen(object):
    '''
    Start a subprocess to run the code of a process object
    '''
    method = 'spawn'

    def __init__(self, process_obj):
        # omitting existing code
        hp, ht, pid, tid = _winapi.CreateProcess(
                    python_exe, cmd,
                    None, None, False, process_obj.creationflags, env, None,
                    STARTUPINFO(dwFlags=STARTF_FORCEOFFFEEDBACK))

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[danegsta]

The caller would need to be aware of whether they're running in win32 to take advantage of the argument, but that's already the case if they're sending any child process signaling (which is the exact situation where this would become helpful).

In use it would look something like:

spawn = multiprocessing.get_context("spawn")

creationflags = 0
if sys.platform == "win32":
    creationflags = subprocess.CREATE_NEW_PROCESS_GROUP

spawn.Process(target=some_target, kwargs=some_kwargs, creationflags)