-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
bpo-30775: Clear potential ref cycle between Process and Process target #2470
Conversation
Besides Process.join() not being called, this was an indirect cause of bpo-30775. The threading module already does this.
Lib/multiprocessing/process.py
Outdated
@@ -110,6 +110,9 @@ def start(self): | |||
_cleanup() | |||
self._popen = self._Popen(self) | |||
self._sentinel = self._popen.sentinel | |||
# Avoid a refcycle if the target function holds an indirect | |||
# reference to the process object | |||
del self._target, self._args, self._kwargs |
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.
I dislike magic attributes which disappear. Would it be possible to assign them to None instead? Please add a reference to bpo-30775 in the comment.
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.
No preference from me, but the deletion is what threading does.
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.
Does it work if run() is called "late" after start()?
Maybe we clear clear the attributes in join() instead?
It's a open question, I don't understand how these things work :-)
run() is called in the child process, so it's safe to clear variables in the parent once the child is spawned (which happens in start()). I don't know what happens if people call run() themselves. They shouldn't :-) |
Oh ok. In this case, it makes sense and it's safe :-) |
Hum, how do you feel about backporting this change to other branches? IMHO it's a bug and it should be backported up to 2.7. |
Yes, that sounds reasonable. |
…ythonGH-2470) * Clear potential ref cycle between Process and Process target Besides Process.join() not being called, this was an indirect cause of bpo-30775. The threading module already does this. * Add issue reference. (cherry picked from commit 79d37ae)
GH-2471 is a backport of this pull request to the 3.6 branch. |
…ythonGH-2470) * Clear potential ref cycle between Process and Process target Besides Process.join() not being called, this was an indirect cause of bpo-30775. The threading module already does this. * Add issue reference. (cherry picked from commit 79d37ae)
GH-2472 is a backport of this pull request to the 3.5 branch. |
…ythonGH-2470) * Clear potential ref cycle between Process and Process target Besides Process.join() not being called, this was an indirect cause of bpo-30775. The threading module already does this. * Add issue reference. (cherry picked from commit 79d37ae)
GH-2473 is a backport of this pull request to the 2.7 branch. |
Besides Process.join() not being called, this was an indirect cause of bpo-30775.
The threading module already does this.