-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
bpo-31308: If multiprocessing's forkserver dies, launch it again when necessary #3246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
TODO: investigate what happens with previously-launched processes. Edit: done. |
…race condition in test_many_processes.
…nto detect_forkserver_death
|
@applio, I'm planning to merge this soon. |
|
|
||
| proc.join() | ||
| self.assertTrue(evt.is_set()) | ||
| self.assertIn(proc.exitcode, (0, 255)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
I don't see/get where you assert that a new process is started.. something like :
new_pid = _forkserver._forkserver_pid # EDIT removed typo assert
assert new_pid is not None and pid != new_pid
or did I miss something ?
Regards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed I don't. I'm not sure it's important, though, since what matters is that the Process API continues working properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. self.Process(..) does that indeed.
|
Added comments on the issue tracker (at https://bugs.python.org/issue31308). In short, I like the idea but I think we need to be more explicit about what we ask the forkserver to do. |
…n when necessary (pythonGH-3246) * bpo-31308: If multiprocessing's forkserver dies, launch it again when necessary. * Fix test on Windows * Add NEWS entry * Adopt a different approach: ignore SIGINT and SIGTERM, as in semaphore tracker. * Fix comment * Make sure the test doesn't muck with process state * Also test previously-started processes * Update 2017-08-30-17-59-36.bpo-31308.KbexyC.rst * Avoid masking SIGTERM in forkserver. It's not necessary and causes a race condition in test_many_processes.. (cherry picked from commit fc6b348)
…n when necessary (GH-3246) (#4252) * bpo-31308: If multiprocessing's forkserver dies, launch it again when necessary. * Fix test on Windows * Add NEWS entry * Adopt a different approach: ignore SIGINT and SIGTERM, as in semaphore tracker. * Fix comment * Make sure the test doesn't muck with process state * Also test previously-started processes * Update 2017-08-30-17-59-36.bpo-31308.KbexyC.rst * Avoid masking SIGTERM in forkserver. It's not necessary and causes a race condition in test_many_processes.. (cherry picked from commit fc6b348)
… necessary (python#3246) * bpo-31308: If multiprocessing's forkserver dies, launch it again when necessary. * Fix test on Windows * Add NEWS entry * Adopt a different approach: ignore SIGINT and SIGTERM, as in semaphore tracker. * Fix comment * Make sure the test doesn't muck with process state * Also test previously-started processes * Update 2017-08-30-17-59-36.bpo-31308.KbexyC.rst * Avoid masking SIGTERM in forkserver. It's not necessary and causes a race condition in test_many_processes.
https://bugs.python.org/issue31308