> subprocess doesn't use a shell by default, and I don't think that
> multiprocessing uses a shell to start Python.
>

No, but we precisely want subprocess/multiprocessing-created processes
to be in the same process group.

> To simplify the implementation, I propose to patch multiprocessing
> and/or subprocess to register the pid of the child process in a list in
> the faulthandler module.
>
> It would be better if these modules unregister pid when a subprocess
> exits, but it's not mandatory. We can send a signal to a non existant
> process. In the worst case, on a heavy loaded computer, another process
> may get the same pid, but it's unlikely. I'm quite sure that
> multiprocessing and subprocess already handle the subprocess exit, so it
> should be quite simply to add a hook.
>

It'll be intrusive and error-prone: for example, you'll have to reset
this list upon fork().
And sending a signal to an unrelated process is risky, no?

>> > subprocess can execute any program, not only Python.
>> > Send an arbitrary signal to a child process can cause issues.
>> Well, faulthandler is disabled by default, no ?
>
> Yes, but I prefer to interfer with unrelated processes if it's possible.
>

Well, those processes are started by subprocess, and this would be
enabled only on demand. I find it less risky than sending a signal to
a completely unrelated process.

> faulthandler.enable() installs a signal handler for SIGSEGV, SIGBUS,
> SIGILL and SIGABRT signals. (SIGKILL cannot be handled by the
> application.)
>

We could use one of these signals.