Charles-François Natali <neolo...@free.fr> added the comment: > 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12413> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
