Charles-François Natali <neolo...@free.fr> added the comment: > 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. ---------- _______________________________________ 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