Avoid reference cycling by the garbage collector during response reading #2932
+4
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request check-list
$ tox
pass with this change (including linting)?Description of change
This won't meaningfully affect most users, so I won't feel bad if this is closed :-)
It's often important for performance to control when garbage collection runs and to reduce the need to run garbage collection in the first place.
During AbstractionConnection.on_connect, it's common to raise and catch ResponseError, since e.g. CLIENT SETINFO is very new. However, because response is in a local, it creates ref cycles that keep all locals in all calling stack frames alive.
The use of a local to store the exception is unfortunate, since exceptions hold references to their tracebacks, which hold references to the relevant frames, which holds a reference to the local exception. See https://peps.python.org/pep-0344/#open-issue-garbage-collection and https://peps.python.org/pep-3110/#rationale
This breaks the cycle by deleting the local when we raise, so frames are destroyed by the normal reference counting mechanism.
Fix suggested by JelleZijlstra