> You mean that the tracebacks of children should be dumped on a timeout of the parent? Or do you also want them on a segfault of the parent? In my experience, the most common problem with the multiprocessing and subprocess modules is the hang.
>

Well, a segfault is due to the current process (or sometimes to
external conditions like OOM, but that's not the point here), so it's
not really useful to dump tracebacks of child processes in that case.
I was more thinking about timeouts.

> The timeout is implemeted using a (C) thread in faulthandler. You can do more in a thread than in a signal handler ;-) A hook may be added to faulthandler to execute code specific to multiprocessing / subprocess.
>

Yes, but when the timeout expires, there's no guarantee about the
state of the interpreter (for example in issue #12352 it was the GC
that deadlocked), so I guess we can't do anything too fancy.

> In which case is Python the leader of the group? Is it the case by default? Can we do something to ensure that in regrtest, in multiprocessing tests or the multiprocessing module?
>

Yes, it's the case by default when you launch a process through a shell.

> The subprocess maintains a list of the create subprocesses: subprocess.alive, but you need a reference a reference to this list (or you can access it using the Python namespace, but it requires the GIL and you cannot trust the GIL on a crash).
> Does multiprocessing maintain a list of child processes?

Yes, we don't have any guarantee about the interpreter's state, and
furthermore this won't work for processes calling fork() directly.

> 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 ?

> By the way, which signal do you want to send to the child processes? A test may replace the signal handler of your signal (most test use SIGALRM and SIGUSR1).
>

Hum, SIGTERM maybe? Don't you register some fatal signals by default?