-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
CallbackRegistry fix #4118
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
Merged
Merged
CallbackRegistry fix #4118
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
4ec886d
Ensure connect() does not add duplicate callbacks. Fix if stmt.
OceanWolf 59f77aa
Improved Garbage Collection
OceanWolf 52f9e5a
Bug fix, speed-up, and safer-than-sorry.
OceanWolf 8864e5c
Nits
OceanWolf d404e35
Even better GC and tests!
OceanWolf 03d97f2
Improved GC for python3.
OceanWolf File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Nits
- Loading branch information
commit 8864e5c2d22899ca111efcc269eddd299e5ef70c
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
What are the life cycle rules on the reference to this object that the ref assigned to
self.inst
holds?[edited for clarity]
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.
Still not crystal clear, I think you ask about the life-cycle of
cb.im_self
?In which case, the same life-cycle as if it weren't here, from the definition of a weakref, it doesn't affect the life-cycle of the object it holds, i.e. as soon as the object looses all non-weakref-references it will get destroyed and GC'ed.
prints
because var looses scope as soon as the function ends and thus gets destroyed.
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.
Even fuller example:
prints
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 suspect that I am just being dense here. I am worried about the circular reference that the
Proxy
objects holds a (hard) ref to the weakref and the weakref holds a (I assume) hard ref back to the object. But I think that is ok as if the weakref dies the call-back will be be triggered and presumably released. However in the case where we lose all refs to theProxy
object, there is the 3 element cycle (proxy.inst
->ref
->proxy._destroy
). But, again, I think that is the correct behaviour as if you register a call-back function you expect it to always run and keeping the proxy object around in probably the right move.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.
If I understand you correctly, by
object
you refer toCallbackRegistry
. Proxy holds no hardrefs back toCallbackRegistry
, you see in_BoundMethodProxy.add_callback()
I used a_BoundMethodProxy
, aka weakref back toCallbackRegistry
, only level one recursion used here (as we don't add a callback to the callback's callback), so no worries.In the case where we lose all hardrefs to the object held in the
Proxy
object, the 3 element-cycle will run, and callback to all the callbacks still there (I added the try except here to deal with that).In the case where we loose all hardrefs to the proxy object itself, then nothing happens because nothing needs to happen, it has no hardrefs to it so it just gets GC'ed like any other object.